为什么有些公司代码不写注释？

这种现象不仅是在小公司小团队中司空见惯，就算在大公司，以及大团队中的开源项目里，也是屡见不鲜。

上图是我在阿里的 Druid 项目源码里截的。DruidDataSource 是 Druid 重度使用的核心类，非常关键，可是哪怕这种关键的核心类，也见不到什么注释。

这张图则来自阿里的另一个著名开源项目Dubbo。DubboProtocol 是 dubbo 协议的实现类，而 dubbo 协议是 Dubbo 项目中最常见，使用最频繁的默认协议，一样没什么注释。

没有注释对我们读代码带来了很多的不便之处。就像扔给你一个数码产品，上面堆叠着密密麻麻的功能按键，但是却没有给你说明书。

那为什么代码注释消失了呢？

我尝试总结一下原因：

1. 国内程序员的职业环境对加注释不友好

在国内这种环境里，程序员们每天在苦闷的 996 中挣扎，各种大活小活不断地做着，正常写代码都忙得不可开交，加注释更是进一步提升了工作量，没人喜欢自己给自己加工作量的。

咱们想想，在费劲巴拉地写完一大堆代码之后，经过反复自测修改之后，好不容易调通了，脑子已经晕乎乎的了，你此时会有多大心思去写这段注释呢？

又再想想，你可能想着要给代码加注释呢，突然这边产品拉你开会，又或者那边运营告诉你，需求变了，刚写好的代码还得再改改……此时，你还有给代码加注释的念头吗？

另外，注释这事儿，写好了是很费精力的。一般来说，一段好的注释，要能在有限的行数之内说明出：被它注释的代码到底做了什么，是个怎样的概念以及为什么会写这段代码。

写注释麻烦不说，关键是注释还不算咱们程序员的工作量。

程序员的工作是把业务用程序实现，工作结果里不看你注释了多少代码，也不看你注释写的好还是坏，只看你的程序是不是写完了，满足了需求没有，会不会上线出什么问题。

至于注释，它滚出了程序员兄弟们的 KPI。有多少公司能像 Google 那样去 Review 代码的？BAT 有一个算一个，都差点意思。

所以，国内程序员们糟糕的环境，是代码注释少的首要原因。

2. 看待注释的方式出现了变化

Java 是一门面向对象的语言，从它出世以来，业界就不断地为 Java 制定了数不清的规范。

在 2008 年，集这些规范于大成的《Clean Code》—— 中文名叫《代码整洁之道》这本书出现了。

在《代码整洁之道》中有个理念就是，注释是为了弥补代码表达能力不足的一种不得已的做法。如果代码能表达清楚，那就没必要写注释。

甚至，这本书的作者认为写注释都需要用 failure 这个词来形容，也就是说，如果你写了注释，那就说明你的代码不够好，你写好代码的努力失败了。

这个理念在业界也被不少大牛们认可了。所以，后面就有越来越多的人认为：代码写的够好，就不用写注释了。

如果大家有空，可以去看看《代码整洁之道》的第四章，里面详细说明了这种如今被业界不少人接受的关于注释的理念。

所以，“好代码不需要注释”这种观点也是造成注释少的一个原因。

3. 注释没有规范，导致质量参差不齐

很多团队里，是没有注释规范的。对怎么注释，在哪里注释没有任何规定，随意程序员们自由发挥。

这就麻烦了，注释一旦写了，它就很关键了。因为

错误的注释，比没写注释还祸害人。

注释写的很差，那不仅没起到注释本应该起到帮助读代码的作用，反而还可能影响读代码，甚至还能把人带坑里。

如果没有注释规范，往往经常就会出现有人做的好有人做的差的情况。

比如，有人到处加注释，i = i + 1; //把i加1连这种简单代码都恨不得加注释，这就有点脱裤子放屁了。

还有的人写注释了，但是需求变了，代码改了之后，注释懒得改了。又或者是改代码的人不是原作者，新人改完之后压根就没意识到要改注释。

所以，如果没有规范，很多程序员对注释没有什么正确的概念，没写好注释由此还引来了埋怨……久而久之，就没人爱干加注释这件事了。

Tags：

转载：感谢您对半点优化网(www.bdxc.net)网站的认可以及对作品的青睐，欢迎各位朋友分享到个人网站或朋友圈。转载请说明文章出处“半点优化网”。/qyseoyh/41958.html

很赞哦！ ()