我的回答：要。
一开始的时候，我并没有这种疑惑。上学的时候，课本和老师都强调要；听入门级的视频也告诉我要；而且自己写的代码就是自己亲生的孩子，如果我不写代码，那么过一段时间，就连亲儿子都不认识，似乎十分悲催。
让我产生疑惑的原因是——因为遇到了不写注释的同事，而且经验比我多，见识也比我丰富。事实上，他代码的逻辑、结构都比较清晰。然后，我回想起了，似乎不爱写注释的不止一个人。
据说网上流传有大神说过：“代码就是最好的注释”，“烂代码才需要注释”。其实我很想知道是哪个大神说的。
论“代码就是最好的注释”
认为“代码就是最好的注释”，是因为如果一个底层清晰，逻辑完整、命名规范且完整、架构清晰。那么代码就可以一目了然，根本不需要什么注释。
首先，要肯定，这样做肯定能让我们更看得懂代码。想起以前看的XXX果冻广告：“回家是最好的礼物”。既然是最好的礼物，为什么还带XXX果冻回家呢？我的理解是：最好的礼物带回家，第二好的也可以带。所以，不要说有最好的东西，其他的就不要了。
我不敢不写注释的原因是：我英文不好和我水平不够。英文不好，注定了我很难望文生义。常见的getUser、getRole 自然没问题，遇到不常见的，我自然要查字典，总的来说，我做不到一目了然，除非很小的程序。当然，让我写代码时，如果类名或方法名不恰当，好歹有中文注释作伴。水平不够，所以，不能保证代码不出错；但是还有两个不能保证：不保证不出错、不敢保证没有注释的时候就能一目了然，即使是自己的代码。那么，还是需要老老实实的写上代码，免得自己看不懂，或者别人看不懂。
如果你英文够好并且水平很高？那么你自然可能很有话语权：别人说1+1 = 3 ，我会认为他胡说；你说的话，我会认为是否涉及到我未知的领域。我觉得，我们还是需要有一个认知：项目是需要协作的。能够让水平低一些的人也能很快入手你的项目，你是否会更轻松？若是遇到一团乱麻的代码，有点注释，是不是更好的？
知识是共享的，团队需要协作的，更接近通俗易懂的东西，才更容易流传千古。知识和技能也需要让更多人懂，才能壮大。
论“烂代码才需要注释”
认为“烂代码才需要注释”的底层思维和“好代码不需要注释”一样。
北京的路方方正正 = “好代码” ；重庆的路弯弯绕绕 = “烂代码”。比喻不恰当，对重庆的朋友表示歉意。
可是，北京和重庆的路上，都有指示牌。如果在没有地图或者导航的情况下，人们在北京迷路的概率小于重庆。似乎，有导航，在重庆也更容易迷路。北京有没有，只认为是好路，就没有指示牌？
我们看看，什么样的路没有指示牌？乡间小路。为什么？因为走的人少，几乎没有外来人口。
所以……
而且，个人认为，如果认为“烂代码才需要注释”。那么，自认为自己写的代码是好代码，是不合适的——至少不是最好的。
论“有些注释影响阅读”
- 认为注释影响阅读的观念包括几种：
- 有的人表达能力不行，写出来的注释很令人费解。
- 许多人写的注释与实际功能不同步。
- 有些注释无意义。例如：
a = 1 ； // 设a 的值为1
- 注释中被放了大量暂时不用的代码。下一个接收的人，想删除它，又不敢。
第1点和第3点有些像：注释对人毫无帮助，甚至啰嗦，但本质上还是有区别的。回想起第一个“hello world!”的时候，我似乎也添加了“打印’hello world!’”的注释。入门的时候，确实水平不够，没有这句注释，我不能快速的知道这句话的意思。
关于第2点，本人的不会出现这个问题。只能说，部分人没有养成真正的写注释习惯。
似乎，写注释真的是不友好的？
如果有一个人字迹潦草，不辩牛马，没有人能懂，你是不是可以认为手写的字是不能让人看懂的？
有的人表达能力不行，你又怎么能保证它的项目名、空间名称、类名、对象名、变量名的表达能力就行。短短的一个单词，就把意思明了？
不是注释影响阅读，是“有的”注释影响阅读。所以，改了就好了。如果是在改不了，那么，我也没有任何办法。
“代码是最好的注释”就不需要写注释了吗？是告诉你，怎样写代码更容易读懂。“烂代码才需要注释”？事实上，见到的官方源码是有注释的，而且注释语言有规律。好的代码、好的程序、更需要注释，因为它是向下兼容的，让更多的人看懂。“有些注释影响阅读”，做的不好，可以改进吗？