boss途：写注释的程序已经过时了。听他一解释，果真有道理
boss说：写注释的程序已经过时了。听他一解释，果真有道理。
boss是美国回来的博士,曾经在XXXX工作，貌似相当的牛叉哦。。。。
今天他看了我的代码，说：不要在程序里面写comments .
我说：为什么？不好吗？
他说：不是不好，而是不要，不允许你这么做。
“我不懂。跟我说说呗。”
“这东西早就过时了，都已经是30年前的事情了。 曾经有许多遗留下来的代码，也有注释，但是后期维护代码的人员，往往总是改了代码而不改注释，导致后面的童鞋看注释是一种说法，看代码又是另一种说法了。所以说，这样不仅仅没有好处，反而对不利，所以，代码就是最好的文档，看文档就看代码，代码就是最终的文档。只是我们在编写变量名的时候，还是要遵守 ‘看名字就知其意’的习惯，同时，敏捷开发也有一个习惯，就是把方法名写全名，让人一看即明白，而少些缩写 ，别让别人去猜。。”
“果然有道理。。”
------解决方案--------------------
谬论 那是他看的代码都比较简单或许是他恰好能理解，假如说是他不能理解的代码，他将如何面对呢，再说了 加入注释又不增加程序的体积，何乐而不为
------解决方案--------------------
1. 那boss纯粹是一家之言，一孔之见而已。
2. 楼主不需要迷信国外回来的什么博士，他们水平未必就很高。我的partner是UC Berkley回来的Computer Science 的PhD(本科是北大的，从学历的角度看，你的boss非常可能不会比他牛叉吧？)，虽然他有很多长处，但从纯技术而言未见其过人之处。总之奉劝楼主不要被牌子吓到。
------解决方案--------------------
以我们广州人的俗语来说，这种行为叫“斩手指避沙虫”。
------解决方案--------------------
怎么能说加注释不好了，应该是修改代码的没去修改注释才是正解！
------解决方案--------------------
牛逼，
------解决方案--------------------
其实问题在于“改了代码没改注释”。 注释躺着也中枪
------解决方案--------------------
写好注释很难，但这不意味着不需要写注释。。
------解决方案--------------------
++,根本就不是注释的问题
------解决方案--------------------
难得啊。
------解决方案--------------------
同意boss观点，但象qsort，A*，……等复杂或怪异的算法、数据结构除外。
------解决方案--------------------
改了代码没改注释 这确实是实际情况，这不是写注释的错误，而是没有认真对待注释的结果。
但是，我始终认为，注释是对那些晦涩的代码的解释以及代码接口的签名和契约说明。
很多时候，代码是优化过的，往往一眼看不出来，此时才需要注释，甚至很多优化的算法，需要些专门的文档来说明和解释。
我不喜欢那种为了注释而注释的代码。
代码就是文档，这句话没有错，如果是一个程序员，看代码都看不懂，那么还写什么程序呢？
就像for 循环的 i, j 这些单字母的变量名都不应该乱写。
------解决方案--------------------
让代码自解释这个是应该的，程序员基本的编码规范
不在代码里做注释，那么你得写详细的规格文档，事实上也是另一种注释罢了
所以不管怎么说都是要有注释的，这个问题不是注释的问题，还是没有改注释的问题
另外：注释并不是说一定要写的代码中，也可写在代码外，请注意
------解决方案--------------------
注释还是必要的吧
------解决方案--------------------
顶。。从不迷信和盲从
------解决方案--------------------
有点片面吧，一个超过万行甚至更多的代码，没有注释，那是什么感觉啊
------解决方案--------------------
他说的是敏捷开发
------解决方案--------------------
大部分情况赞成boss的观点
------解决方案--------------------
一定要加注释的，最近还在复习我自己写的代码呢，两个星期没看，现在要修改起来连自己写的都看不懂了
------解决方案--------------------
看到一句话比较好 注释需要注释的是WHY 而不是WHAT或HOW
你们老板也说了 改了代码没改注释，
那就要规定 先改注释再改代码。不然每次理解都要从头回忆的
------解决方案--------------------
我也讨厌注释 有没有用到复杂的算法 这点代码会有人看不懂？
当然 方法名 参数要命名规范
boss是美国回来的博士,曾经在XXXX工作，貌似相当的牛叉哦。。。。
今天他看了我的代码，说：不要在程序里面写comments .
我说：为什么？不好吗？
他说：不是不好，而是不要，不允许你这么做。
“我不懂。跟我说说呗。”
“这东西早就过时了，都已经是30年前的事情了。 曾经有许多遗留下来的代码，也有注释，但是后期维护代码的人员，往往总是改了代码而不改注释，导致后面的童鞋看注释是一种说法，看代码又是另一种说法了。所以说，这样不仅仅没有好处，反而对不利，所以，代码就是最好的文档，看文档就看代码，代码就是最终的文档。只是我们在编写变量名的时候，还是要遵守 ‘看名字就知其意’的习惯，同时，敏捷开发也有一个习惯，就是把方法名写全名，让人一看即明白，而少些缩写 ，别让别人去猜。。”
“果然有道理。。”
------解决方案--------------------
谬论 那是他看的代码都比较简单或许是他恰好能理解，假如说是他不能理解的代码，他将如何面对呢，再说了 加入注释又不增加程序的体积，何乐而不为
------解决方案--------------------
1. 那boss纯粹是一家之言，一孔之见而已。
2. 楼主不需要迷信国外回来的什么博士，他们水平未必就很高。我的partner是UC Berkley回来的Computer Science 的PhD(本科是北大的，从学历的角度看，你的boss非常可能不会比他牛叉吧？)，虽然他有很多长处，但从纯技术而言未见其过人之处。总之奉劝楼主不要被牌子吓到。
------解决方案--------------------
以我们广州人的俗语来说，这种行为叫“斩手指避沙虫”。
------解决方案--------------------
怎么能说加注释不好了，应该是修改代码的没去修改注释才是正解！
------解决方案--------------------
牛逼，
------解决方案--------------------
其实问题在于“改了代码没改注释”。 注释躺着也中枪
------解决方案--------------------
写好注释很难，但这不意味着不需要写注释。。
------解决方案--------------------
++,根本就不是注释的问题
------解决方案--------------------
难得啊。
------解决方案--------------------
同意boss观点，但象qsort，A*，……等复杂或怪异的算法、数据结构除外。
------解决方案--------------------
改了代码没改注释 这确实是实际情况，这不是写注释的错误，而是没有认真对待注释的结果。
但是，我始终认为，注释是对那些晦涩的代码的解释以及代码接口的签名和契约说明。
很多时候，代码是优化过的，往往一眼看不出来，此时才需要注释，甚至很多优化的算法，需要些专门的文档来说明和解释。
我不喜欢那种为了注释而注释的代码。
代码就是文档，这句话没有错，如果是一个程序员，看代码都看不懂，那么还写什么程序呢？
就像for 循环的 i, j 这些单字母的变量名都不应该乱写。
------解决方案--------------------
让代码自解释这个是应该的，程序员基本的编码规范
不在代码里做注释，那么你得写详细的规格文档，事实上也是另一种注释罢了
所以不管怎么说都是要有注释的，这个问题不是注释的问题，还是没有改注释的问题
另外：注释并不是说一定要写的代码中，也可写在代码外，请注意
------解决方案--------------------
注释还是必要的吧
------解决方案--------------------
顶。。从不迷信和盲从
------解决方案--------------------
有点片面吧，一个超过万行甚至更多的代码，没有注释，那是什么感觉啊
------解决方案--------------------
他说的是敏捷开发
------解决方案--------------------
大部分情况赞成boss的观点
------解决方案--------------------
一定要加注释的，最近还在复习我自己写的代码呢，两个星期没看，现在要修改起来连自己写的都看不懂了
------解决方案--------------------
看到一句话比较好 注释需要注释的是WHY 而不是WHAT或HOW
你们老板也说了 改了代码没改注释，
那就要规定 先改注释再改代码。不然每次理解都要从头回忆的
------解决方案--------------------
我也讨厌注释 有没有用到复杂的算法 这点代码会有人看不懂？
当然 方法名 参数要命名规范