关于代码注释的一些思考

什么时候该写注释，什么时候不该写。

「好代码本身就是最好的注释」这句话被过度简化了。

该写注释的场景

• 业务规则：代码无法表达「为什么这样做」
• Workaround：记录为什么绕过了常规方案
• TODO/FIXME：标记已知但未解决的问题
• 公共 API：使用者不应该需要阅读实现

不该写注释的场景

• 解释显而易见的代码逻辑
• 记录 Git 历史应该记录的信息
• 注释掉的旧代码（删除就好）

一句话原则

好的注释解释 Why，好的命名解释 What，代码本身解释 How。

← 返回文章列表