你们猜猜，作为程序员你们最讨厌做的事是什么？产品经理频繁修改需求？不是。测试天天给你提交不可理喻的 bug ？也不是。接手别人交接的如火星文一样的烂代码？其实也不是。
其实我搞了一个文字游戏，叫最讨厌做的事，而不是最讨厌的事，上述几点，可能是你最讨厌的事，但是你又可能不能不做。有一种令人发指的讨厌就是你讨厌别人不去做，而自己又毫无察觉的在犯这个错误，却心安理得，而程序员在什么情况下，才会这样做呢？
程序员最讨厌的四件事：
写注释、写文档、别人不写注释、别人不写文档。
不错，今天我们就来谈谈程序员最讨厌做的这件事：写注释。
程序员该不该写注释？
其实对于写注释这件事来说，还是有一定的争议的，争议其实不在于该不该写注释，而是在于不要过多的写注释，注释多了，反而会让你感觉整个代码比较混乱不堪，影响视觉。而且有人为什么不太鼓励大家过多的去写注释呢？因为代码即注释，何为代码即注释？代码是具有自解释功能的，高质量，命名规范的代码，其实程序员应该一眼就能够看懂这段代码的功能作用是什么？
所以，程序员到底该不该写注释？要我说：该，但是要注意分寸。
如何注意分寸？
优秀的程序员可以少写注释
优秀的程序员都是懒的。因为懒，他才会写出各种各样的工具来替自己干活。因为懒，他才会想办法避免去写无聊重复的代码——因此避免的代码的冗余，削减了代码的维护成本，使重构变得更加容易。最终，这些由于懒惰激发出的动力而开发出的工具和最佳编程实践方法提升了代码和产品的质量。
上面我们说了，代码即注释。作为一个优秀的程序员，他们懂得注释不是用来翻译程序代码的，用代码能说清楚的东西，就自然不用费脑子去写注释了，集中精力写出最优雅、高质量的代码才是首要的。代码是具有自解释功能的，如果你写的一个函数方法，命名非常规范，有一个好的方法名，里面有很多可读性很强的好的变量名，函数里代码又不是特别多，最多二三十行。别的程序员一眼就看懂了，知道这个函数的功能作用，这就是代码的自解释功能。这就告诉了我们命名的重要性，如果你能够做到你的命名能完全、准确地描述所代表的事物和功能，这无疑提高整个项目代码的可读性，可以不写注释。
但是如果一个函数上百行代码，甚至更多，还是需要写一定的注释的，甚至在一个重要的业务逻辑处理的地方，还是需要注明一些注释的，毕竟时间久了，业务逻辑不熟悉了，看代码确实有些费劲。在重要的业务逻辑代码面前，还是需要一定的注释。当然在命名的时候，再优秀的程序员可能也会遇到所命名的方法和函数，并不能准确代表所起的功能，这时写注释就很有必要了。记住：与人方便就是与己方便。
初级中等程序员还是得写注释
作为一个入门，初级或者中等的程序员，在自己代码质量不高的阶段，时刻提醒自己养成一个好的写注释的习惯还是很有必要的。人不可能天生就是写程序的料，也不可能一开始马上就能够写出符合规范的高质量的代码。所以，前期记住一定得写注释。
为什么很多程序员不愿意接手别人写的代码，是因为有一个问题就是必然存在的。每个人的编码风格不一样，命名方式和规范不一样，这就是作为初级和中等程序员最容易犯的错误。其实每个公司都应该有自己的编程规范才可以。由于程序员代码的个性化，就造就了代码的多样性。再加上没有注释，谁还愿意看？
我感觉作为一个程序员，都应该有一个强迫自己写出高质量代码的习惯，多读读系统源码，别人的开源代码，看看高手都是如何写函数，做封装的。慢慢的，一步一步的去改善自己的写代码的质量，慢慢的尝试在感觉自己代码质量比较高的时候，让你同事看看，如果没有注释，他能看懂了，那这里就少写注释，或者尝试不写注释。
为什么谈这个话题
谈这个话题的原因
对，为什么谈这个话题呢？因为有很多程序员写代码总有一种非常非常不好的习惯，那就是一段代码不用了，注释掉，但是他心里还总想着感觉这段代码以后可能还会用。所以就留着，不删掉，但大多数情况下，过几天就忘了，结果代码里到处都是注释，没有一句是有用的。
接下来好了，接手的读代码的人也不敢删，一直留着，留着，留着，留着……直到永远。
你们大声告诉我，你们是不是有这种习惯？是不是有这种心理？
注释维护
我想说，注释也是需要维护的。很多人都没有意识到注释维护的重要性。怎么说呢？不写注释坑人，比不写注释更坑人的就是写了注释，功能变了，不修改注释的人。比如：
今天是程序员小王写了一个处理业务逻辑的功能方法，功能是炒菜。过了两个月后，需求变了，人家客户不喜欢吃炒菜，需要换成了煮菜了。这时程序员小陈就在炒菜的功能方法上直接修改了，把功能改成了煮菜。但是注释上写的还是炒菜。又过了两个月，客户需求又变了，客户吃腻了煮的菜，要求改成蒸饭。这时项目经理说：小郭，你把那个煮菜功能给我换成蒸饭。这时，程序员小郭，找啊找，找遍了注释，发现没有煮菜功能，一气之下，算了，自己写吧，自己又写了一个蒸饭的功能函数。之后带有炒菜注释的煮菜功能，在接下来的一个又一个程序员都不敢删，也不管了。
看到了，注释不维护，是不是很不好。这只是其中一个方法，如果你修改了大部分的方法，又没有修改注释，接下来接手的程序员又不敢乱动，还看不懂，自己又重新写，代码冗余，混乱不堪，之后越来越烂，代码越来越没人管了，也不想干了。
总结
代码即注释，写注释要注意分寸。如下：
-
用高质量的代码代替注释。
-
在复杂函数和重要的业务逻辑面试，还是必须要写注释的。
-
注释需要维护，不是写了就好。不维护，还不如不写。
-
要学会命名，遵守规范，这样才能够培养出好习惯。