为什么程序员都不喜欢写注释？

大家好，我是啊粥。

今天我们来聊一下关于代码注释的问题，开始阅读正文之前，你先想 3 个问题：

1. 你平时写代码的时候会写注释嘛？
2. 你的注释是怎么样写的，主要都表达些什么？
3. 你一般会在什么样的代码里写注释？

好了，我们正文开始。

首先，我个人刚开始写代码的时候，非常喜欢写注释，我一般会把代码思路先用文字表述出来。然后分成 1 2 3 4 每一步要干什么，怎么干。

然后写完之后开始在每个步骤下边填代码，这个时期我的代码注释量是非常高的。

但是后来随着技术熟练程度的提高，以及代码水平的提高，我的注释量就逐渐减少了。

并不是我觉得自己牛逼了不用写代码了，也不是我想专门给后人挖坑，纯粹是我觉得不太有必要了。

因为一方面我认为当你可以写出相对比较好的代码的时候，你的代码就是你的注释，你的命名、你的日志以及你的单元测试等等所有东西会共同构建成你的完整注释，最终他们合在一起形成的注释远比你一字一句写出来的注释要更清楚更实用。

并不是只有 // 后写的才叫注释。

通常来说，我们去阅读理解一段代码，一般我们会有下面三种诉求：

1. 这代码是用来解决什么的问题的?
2. 怎么使用这段代码，有没有什么注意事项？
3. 这个代码的实现细节是什么，它是如何运作的？

对于第一点来说，Why 是很重要的，但我们需要知道，【代码注释通常来说都是微观的，不是宏观的】。

对于宏观的东西都会写在需求和设计文档中，那些微观的 Why 如果能写成注释确实是挺好的，因为代码再简单再易读也不会告诉你 Why，这一点上我还是非常认同的。

但同理，这个 Why 写成日志好像也是可以的，比如：“正在解决 XXX 问题...”，你想想是不是这么个道理？

对于第二点来说，怎么使用这个函数，这个类，有没有什么注意事项。

其实，我们需要的可能是一些示例，最好是可以直接拷贝复制后改一改就可以用的示例，毕竟大家都知道写代码的意义就在于是粘贴复制

。

但是呢，这些示例完全可以写成 Unit Test 单元测试案例，Positive 的案例告诉我们正常应该怎么用，Negtive 的案例告诉我们有哪些注意事项，不要这么用。

这比单纯的代码注释要强数百倍，不是吗？

难不成跟具体的例子相比，你更喜欢看一段话，告诉你：“请不要 XXX 使用这个函数”？

对于第三点来说，你要搞清楚代码是怎么运作的，我们每个写代码的人都知道，注释对于你搞清代码是怎么运作的几乎是没有什么帮助的。

最好的方式就是打一些断点，然后 Debug 一下代码，看代码运行时的那些 Context（变量里的值，状态，条件，执行路径等）是什么样的？

这时，注释是低效的，把这些上下文打在 Debug log 里输出才是最高效的。

生产环境可以选择关掉 Info 或 Debug 级别的日志，然后开发的时候这些日志其实比注释可能还好用（如果 Context 输出比较全，且有规范）。

同时日志开关是自如的，完全可以由我们自己来进行控制，当你遇到 Bug 需要调试的时候你打开丰富的 Debug ，之后你可以再把他调回 Info 或者 Error。

我相信以上观点可能很多人是不认同的，但是我说真的，作为初学者你肯定会有一个需要大量注释的阶段，主要是因为你经验还比较缺乏，所谓没有达到熟能生巧的地步。

但时，当你写代码写的足够久了之后，你会发现写得好的代码是自注释的，代码既注释，而重要的地方才写注释，其实就是日志 ……

当然，还有一种情况我是建议写注释的，那就是二笔产品非要提一个不合理的需求导致你有一个不合理的写法，这个时候我希望你能注明“不是我要这么写的，是产品需求要求这样的，我也没办法的”的无奈，免得下一任接受你代码的人骂娘，说你是个菜鸡。

好了，今天的内容就到这里了。

你也可以留言分享你写注释的一些经验给到我们。