注释是写完代码后的"补充说明",学员写完 50 行代码再补两行注释——注释描述的是"代码做了什么"(把 A 赋给 B),而不是"为什么这么做"。好的注释在写代码之前就已存在:先写注释描述意图,再填实现,注释才不会被代码变更甩在身后。错误场景:
-- 处理
local function proc(actor, n)
local r = n * 0.85
if r > 100 then r = 100 end
giveitem(actor, "祝福油", math.floor(r / 10))
end
0.85 是什么?为什么上限 100?半年后无人能答。
注释先描述"为什么"(业务规则),再写"怎么做"(代码实现):0.85 是强化成功率系数,100 是系统上限——业务规则注释化,代码只是规则的翻译。示例代码如下:
-- 烈火剑法修炼系数:基础产出 × 0.85(系统衰减),上限 10 瓶(防囤积)
-- 业务规则:每次修炼消耗 1 本技能书,产出祝福油 1/10 概率翻倍
local function procCultivation(actor, skillBooks)
actor = getplayerbyname(actor)
local baseYield = skillBooks * 0.85
local finalYield = math.min(10, math.floor(baseYield))
if finalYield > 0 then
giveitem(actor, "祝福油", finalYield)
end
sendmsg(actor, 1, "修炼完成,产出祝福油 " .. finalYield .. " 瓶。")
end
本篇的新技术点是"注释三问":为什么是这个值(0.85 的来源)?边界是什么(上限 10)?变了会怎样(影响祝福油产出)?三问齐答的注释才值得写。
三步验证:传入 skillBooks=5,产出应为 math.floor(5 × 0.85) = 4 瓶;传入 20 本应被上限 10 截断;注释里的每个数字(0.85、10)在代码中都有对应变量——注释与代码一一对应。
注释先行的自然延伸是 TODO/FIXME 标记规范:临时方案标 FIXME(必须限期解决),待优化标 TODO(可以长期存在),让技术债可搜索可追踪。示例代码如下:
-- FIXME: 临时用固定值,待接入活动系统后改为动态获取(2026-10 前完成)
local discountRate = 0.85
全站技术干货持续更新:996 引擎 / Lua 实战帖,语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
设计初衷 背包无限装:药水带一百瓶、材料囤到爆——负重没有成本,背包管理沦为无脑囤积。负重系统设计:每件物品带重量,总负重超…
设计初衷 装备栏有武器位没有副手位:副手要么没用、要么变成第二武器直接双倍攻击——副手的定位从来没人讲清。副手装备设计:主手…
底层原理 对不同类型的节点执行不同操作(战绩流水里的击杀、阵亡、助攻各有统计口径),把操作散在类型判断里,每加一种操作就要改…
底层原理 行会的战力由成员战力组成、成员战力由装备组成——"整体"与"部分"要能用同一个接口对待:问行会战力与问成员战力是同…
设计初衷 输出成长只有堆攻击一条路:攻击加成稀释严重(基础 2000 再加 200 体感无几),成长反馈越来越钝。增伤属性设…
业务场景 驻地守御靠玩家人肉站桩:离线时段防务真空。箭塔守御封装:驻地点位部署箭塔(帮会资金建造),箭塔自动索敌(优先最近、…