什么时候该写注释
写代码时，很多人纠结要不要加注释。其实有个简单的判断标准：如果一段代码的作用不能一眼看懂，那就该写注释。比如你用了一串复杂的正则表达式来验证邮箱格式，过两周自己再看可能都得愣一下，这时候注释就特别有用。
还有一种情况是“反直觉”的逻辑。比如某个函数明明可以返回结果，却非要抛出异常，原因可能是业务流程要求必须中断操作。这种背后有隐情的地方，不写注释队友很容易踩坑。
注释不是复读机
很多人写注释喜欢当“翻译”，比如：
// 把 i 加 1
i++;这种注释纯属多余。代码自己已经说得很清楚了，再写一遍只会增加维护成本——改代码还得同步改注释。
真正有用的注释是解释“为什么”，而不是“做什么”。比如：
// 使用 setTimeout 是为了避开 DOM 更新的批量机制
setTimeout(updateUI, 0);这句注释告诉别人这么写的理由，比单纯描述行为有价值得多。
保持简洁，别写小作文
有些人在函数开头写一大段注释，从需求背景讲到实现思路，像写论文一样。其实大多数时候不需要。一行能说清的事，就别拆成三行。
比如这个例子：
/**
* 计算用户折扣金额
* @param {number} price 原价
* @param {string} level 会员等级
* @returns {number} 折扣后价格
*/
function getDiscount(price, level) { ... }参数和返回值标清楚就行，不用额外展开。但如果逻辑复杂，可以补充一句关键说明：
// VIP2 以上用户享受叠加优惠，但总价不低于 50
if (level === 'VIP3') { ... }别让注释撒谎
代码改了，注释没改，是最坑队友的行为。比如原本是按年计算利息，后来改成按月，但注释还写着“每年复利一次”，这种错误比不写注释更糟。
所以修改逻辑时顺手扫一眼旁边的注释，确保它仍然准确。如果懒得更新，不如直接删掉。
用对符号，别影响运行
在办公软件里处理脚本时，比如 Excel 的 VBA 或 Google Sheets 的 Apps Script，注释符号要写对。JavaScript 用 // 和 /* */，VBA 却用单引号。
比如 VBA 中这样写：
' 关闭屏幕刷新以提升性能
Application.ScreenUpdating = False要是写成 // 就会报错。不同语言规则不一样，别套用习惯了。
好代码自己会说话
最好的注释其实是不需要注释。变量命名清晰、函数职责单一，代码读起来就像句子。比如 writeReport() 比 doStuff() 明确得多，calcTax2024() 比 computeNum() 容易理解。
当你发现需要大段注释才能解释清楚时，不妨先想想能不能把代码改得更直白。有时候拆一个长函数，或换个名字，比写十行注释都管用。