你写注释吗？

据统计，每个程序开发人员的工作时间中，只有不到一半的时间是花在写代码上，其它的时间一部分是在阅读别人或者自己以前写的代码，另一部分则是花在代码的导航定位上。
就拿使用eclipse的开发人员来说，你可能只有一部分的时间是集中在编辑器中写代码，而很多时间你会花在其它的像Package Explorer,Open Type,等视图上。
Eclipse的Open Type和Search等功能可以方便我们很快的查找和定位到相应的代码，但这些都是基于代码的查找和定位，开发人员有时更需要根据自己对代码的标记来查找和定位。
Eclise的tasks和bookmarks的视图提供了对代码标记的功能.
Eclipse的task机制提供了以注释的形式在代码里面描述任务的功能，在用ECLISPE开发JAVA的时候，你可以在注释中插入一些预先定义好的任务的标记，像“TODO”，“FIXME”，“XXX”，“HACK”等。利用这些，你可以实现比常规注释更丰富的功能.
通过做下面这个测试,你可以看下你平常注释的特点和你没考虑到的注释的功能.
http://www.surveymonkey.com/s.aspx?sm=aw7dCPMNTKT_2b8qR0sE8YnA_3d_3d

评论

42 楼 jwnest 2009-06-04  

注释还是很重要的，假设你需要去维护别人的代码或者该bug，如果有注释可以很快知道这段代码是做什么的，是不是我需要关心的，如果不是可以马上跳过，看下一部分，如果没有注释，你可能看半个小时也不知道你要找的东西在哪里。
如果你想研究代码的详细内容，注释也是个很好的切入点，可以帮助你的理解，哪怕注释和实际实现不太一样，你好歹比较容易知道哪里不同，当前的实现是不是有问题。
在我们之前项目里，我是鼓励开发人员写注释的，这样会大量减少之后的维护工作量，而且应该得到不错的效果，而且说白了，写好注释要比写好代码容易多了。

41 楼 visualcatsharp 2009-05-27  

黑暗浪子 写道

我是不是要把《clean code》里关于comment那一章全部贴出来？
现在的小孩还真是什么都敢说~

有理由就说出来，不要在这里装b。
不是人人都看过《clean code》，人家也随便能找本书出来是你没看过的。

40 楼 visualcatsharp 2009-05-27  

ozzzzzz 写道

visualcatsharp 写道

ozzzzzz 写道

javadoc这样的东西不是注释，而更加类似一种编程语言？

请说出javadoc不是注释，或者不具体注释的功能理由，如果说不出请收回自己的说话。
还有，如果谁能使用jdk里任何api都不看注释的，我只说尊之为神了。
奉劝一句，说话不要这么绝对！

哈哈，确实有趣。
请问你如何看jdk里面的注视。你给我们演示一下行不。
至于我说javadoc不是注释，理由很简单。这个东西有明确的格式要求，和内容要求，是受到严格约束的。并且我见到的一般情况，这个东西又是对客户开放的。一般情况下，这个东西都会受到严格的审查和多人的评议。质量一般还是可以得到保证的。而你说的注释有个功能吗？
我特别奇怪的是，你们究竟如何看jdk里面的注释的。

一轮自行车由于装了马达，难道就不是自行车了？真是强词夺理。
如果我在公司内部弄了个框架，假设这框架的完美程度已经达到了不需要再作太多的改进的程度下，那么我在这个框架里写的注释的作用跟javadoc的作用类不类似？它严格不严格？至少我答案是肯定的，只是严格的范围和所谓的审查的范围变窄了，只适用于公司内部。难道就因为基本不再变动这个原因失去了它作为注释的理由吗？
至于如何看jdk的注释，我只能老老实实的答你，jdk里的api我还没完全搞懂，例如IO包里有一些类我根本没记得，甚至没看过，但我只能猜想存在着这个类，因为IO这东西其实是操作系统决定的，因此c++/.net/java里都有着类似的体系，很多时候在.net里用过某个类，那么便猜想java里也应该有。这时候难道看注释就错了？

39 楼 黑暗浪子 2009-05-24  

我是不是要把《clean code》里关于comment那一章全部贴出来？
现在的小孩还真是什么都敢说~

38 楼 ozzzzzz 2009-05-24  

visualcatsharp 写道

ozzzzzz 写道

javadoc这样的东西不是注释，而更加类似一种编程语言？

请说出javadoc不是注释，或者不具体注释的功能理由，如果说不出请收回自己的说话。
还有，如果谁能使用jdk里任何api都不看注释的，我只说尊之为神了。
奉劝一句，说话不要这么绝对！

哈哈，确实有趣。
请问你如何看jdk里面的注视。你给我们演示一下行不。
至于我说javadoc不是注释，理由很简单。这个东西有明确的格式要求，和内容要求，是受到严格约束的。并且我见到的一般情况，这个东西又是对客户开放的。一般情况下，这个东西都会受到严格的审查和多人的评议。质量一般还是可以得到保证的。而你说的注释有个功能吗？
我特别奇怪的是，你们究竟如何看jdk里面的注释的。

37 楼 visualcatsharp 2009-05-23  

ozzzzzz 写道

javadoc这样的东西不是注释，而更加类似一种编程语言？

请说出javadoc不是注释，或者不具体注释的功能理由，如果说不出请收回自己的说话。
还有，如果谁能使用jdk里任何api都不看注释的，我只说尊之为神了。
奉劝一句，说话不要这么绝对！

36 楼 ozzzzzz 2009-05-16  

java.lang.Object 写道

黑暗浪子 写道

chenjianjx 写道

我一般都会看，你不会吗？

ozzzzzz 写道

chenjianjx 写道

拜托，你调用java标准包中的某个API之前会把整个方法的源代码看一遍？ 
如果不会，那你又凭什么要求你的同事细阅你的代码呢？
协同开发本来就是基于契约的嘛。好像我找你采购一批螺钉，我只需要知道你的规格就够了，难道我还要知道你是怎么淬火的？ 时间宝贵！

写注释，本来就是软件工程教科书上的理论，怎么在你眼里成了“补充混乱代码”的辅助工具了？

黑暗浪子 写道

说到底你就是不想看代码。如果看代码，你的1根本不是问题。而2就说明了为什么你有1这个说法的原因。
个人认为如果是开发人员看代码肯定要比看注释更能理解整体。不过国内很多代码都比较混乱，因此造成用注释来补充说明的举动。
所以不写注释的前提就是写出简洁，高效，规范的优秀代码。脱离这个前提，不写注释当然是不可能的。

请问你引用java标准包里面某个api的时候会看这个api的注释吗？

一般看了代码，再看不看注释都无所谓。除非你理解不了代码。
不过说老实话，API的注释就是为不想看代码的人准备的。

你调用的那么多的系统类，你会去看他的代码，连native方式你也去看看，难道你不需要注释，你看看java.lang.Math类的源码能看出什么东西来，里面什么也没有。你看看java.awt.Graphics的源码你能看出什么东西来？里面也是什么都没有。所以注释对于API的提供者来说是必须的，否则，你提供的接口别人怎么知道如何调用，有的时候，类库是以JAR的形式给别人的，你不准备注释，难道还要调用者去反编译或者你另外提供源码？
当然，在项目里面有一个清楚的方法名那是很好的，但是我们不能就这样一棍子打死注释。JAVADOC的注释是肯定有存在的必要的。

javadoc这样的东西不是注释，而更加类似一种编程语言。实际上很多工具在代码里面加注释的时候，也是这么做的。
至于你说的调用系统类的时候，我还真不看注释。一个是我用宽屏，而且有两个显示器。一个是我即使没有这个物质条件，我也建议先看手册和帮助。并且如果你用现代IDE的话，参数之类的会有提示，而且会使用ctr+space。
而你们说的那种调一个函数，看一个注释的做法我还真没用过，而且我劝你们也别用。除非这个函数太复杂，以至于你们不跟着他们那个注释就没办法。当然这个时候，我觉得这个函数或者类，一般都是别人提供的，而不是javajdk里面的。在这个时候，我建议你看不看这个注释也是可以选择的。因为写这个难用的东西的人，我相信他的注视和代码也好不到什么地方去，建议你还是先写单元测试，然后一点一点的试着搞吧。
我觉得一个简单的方法或者函数，你看几眼就应该可以明白。而如果你看不明白，那么要么是长，要么是名字太搞，要么是实在是风格奇怪。这样的时候，我也觉得你看注释没啥必要。因为能这么做的人，我实在不能相信他写的注视。

一个程序员写的代码都不能叫我相信，你叫我相信他写的注释？真抱歉，这样的习惯我不可能养成。

35 楼 java.lang.Object 2009-05-15  

黑暗浪子 写道

chenjianjx 写道

我一般都会看，你不会吗？

ozzzzzz 写道

chenjianjx 写道

拜托，你调用java标准包中的某个API之前会把整个方法的源代码看一遍？ 
如果不会，那你又凭什么要求你的同事细阅你的代码呢？
协同开发本来就是基于契约的嘛。好像我找你采购一批螺钉，我只需要知道你的规格就够了，难道我还要知道你是怎么淬火的？ 时间宝贵！

写注释，本来就是软件工程教科书上的理论，怎么在你眼里成了“补充混乱代码”的辅助工具了？

黑暗浪子 写道

说到底你就是不想看代码。如果看代码，你的1根本不是问题。而2就说明了为什么你有1这个说法的原因。
个人认为如果是开发人员看代码肯定要比看注释更能理解整体。不过国内很多代码都比较混乱，因此造成用注释来补充说明的举动。
所以不写注释的前提就是写出简洁，高效，规范的优秀代码。脱离这个前提，不写注释当然是不可能的。

请问你引用java标准包里面某个api的时候会看这个api的注释吗？

一般看了代码，再看不看注释都无所谓。除非你理解不了代码。
不过说老实话，API的注释就是为不想看代码的人准备的。

你调用的那么多的系统类，你会去看他的代码，连native方式你也去看看，难道你不需要注释，你看看java.lang.Math类的源码能看出什么东西来，里面什么也没有。你看看java.awt.Graphics的源码你能看出什么东西来？里面也是什么都没有。所以注释对于API的提供者来说是必须的，否则，你提供的接口别人怎么知道如何调用，有的时候，类库是以JAR的形式给别人的，你不准备注释，难道还要调用者去反编译或者你另外提供源码？
当然，在项目里面有一个清楚的方法名那是很好的，但是我们不能就这样一棍子打死注释。JAVADOC的注释是肯定有存在的必要的。

34 楼 黑暗浪子 2009-05-14  

chenjianjx 写道

我一般都会看，你不会吗？

ozzzzzz 写道

chenjianjx 写道

拜托，你调用java标准包中的某个API之前会把整个方法的源代码看一遍？ 
如果不会，那你又凭什么要求你的同事细阅你的代码呢？
协同开发本来就是基于契约的嘛。好像我找你采购一批螺钉，我只需要知道你的规格就够了，难道我还要知道你是怎么淬火的？ 时间宝贵！

写注释，本来就是软件工程教科书上的理论，怎么在你眼里成了“补充混乱代码”的辅助工具了？

黑暗浪子 写道

说到底你就是不想看代码。如果看代码，你的1根本不是问题。而2就说明了为什么你有1这个说法的原因。
个人认为如果是开发人员看代码肯定要比看注释更能理解整体。不过国内很多代码都比较混乱，因此造成用注释来补充说明的举动。
所以不写注释的前提就是写出简洁，高效，规范的优秀代码。脱离这个前提，不写注释当然是不可能的。

请问你引用java标准包里面某个api的时候会看这个api的注释吗？

一般看了代码，再看不看注释都无所谓。除非你理解不了代码。
不过说老实话，API的注释就是为不想看代码的人准备的。

33 楼 chenjianjx 2009-05-14  

我一般都会看，你不会吗？

ozzzzzz 写道

chenjianjx 写道

拜托，你调用java标准包中的某个API之前会把整个方法的源代码看一遍？ 
如果不会，那你又凭什么要求你的同事细阅你的代码呢？
协同开发本来就是基于契约的嘛。好像我找你采购一批螺钉，我只需要知道你的规格就够了，难道我还要知道你是怎么淬火的？ 时间宝贵！

写注释，本来就是软件工程教科书上的理论，怎么在你眼里成了“补充混乱代码”的辅助工具了？

黑暗浪子 写道

说到底你就是不想看代码。如果看代码，你的1根本不是问题。而2就说明了为什么你有1这个说法的原因。
个人认为如果是开发人员看代码肯定要比看注释更能理解整体。不过国内很多代码都比较混乱，因此造成用注释来补充说明的举动。
所以不写注释的前提就是写出简洁，高效，规范的优秀代码。脱离这个前提，不写注释当然是不可能的。

请问你引用java标准包里面某个api的时候会看这个api的注释吗？

32 楼 ozzzzzz 2009-05-07  

黑暗浪子 写道

chenjianjx 写道

拜托，你调用java标准包中的某个API之前会把整个方法的源代码看一遍？ 
如果不会，那你又凭什么要求你的同事细阅你的代码呢？
协同开发本来就是基于契约的嘛。好像我找你采购一批螺钉，我只需要知道你的规格就够了，难道我还要知道你是怎么淬火的？ 时间宝贵！

写注释，本来就是软件工程教科书上的理论，怎么在你眼里成了“补充混乱代码”的辅助工具了？

黑暗浪子 写道

说到底你就是不想看代码。如果看代码，你的1根本不是问题。而2就说明了为什么你有1这个说法的原因。
个人认为如果是开发人员看代码肯定要比看注释更能理解整体。不过国内很多代码都比较混乱，因此造成用注释来补充说明的举动。
所以不写注释的前提就是写出简洁，高效，规范的优秀代码。脱离这个前提，不写注释当然是不可能的。

软件工程教科书？残念～
这还真不能细说。
JAVA标准包里的API或许可以看作是优秀代码的典范。当然由于历史悠久，它也有很完整的注释。
但是很多API其实根本不需要看它的注释就知道是派什么用处的，不是吗？

这个有啥好不能细说的。
看看这些书的成书年代，再对比对比软件开发的发展史就能明白其中的道理。
其实在代码里面不写注释一个方面是技术理由，另外也有商业理由——很多CASE之类的工具都是在注释里面添加标注的。你写的注释很难保证会不会跟这些鸟东西冲突。而现在的软件工程学者，大多数最终都会走向CASE工具之类的开发者的，所以老人会坚持写，新的或者活着跟着潮流的就都不主张写。
而且这里其实也有另外一个问题，那就是如果自己喜欢写些小工具的话，一般也不喜欢别人写注释。因为注释显然是这些工具操作的第一个想的到点，其他的用log之类的事情，一般都是用作输出，不会用作输入和扫描之后的标记等等。所以只要是自己写工具，一般也喜欢不主张别人写注释，留着给自己用。

31 楼 黑暗浪子 2009-05-07  

chenjianjx 写道

拜托，你调用java标准包中的某个API之前会把整个方法的源代码看一遍？ 
如果不会，那你又凭什么要求你的同事细阅你的代码呢？
协同开发本来就是基于契约的嘛。好像我找你采购一批螺钉，我只需要知道你的规格就够了，难道我还要知道你是怎么淬火的？ 时间宝贵！

写注释，本来就是软件工程教科书上的理论，怎么在你眼里成了“补充混乱代码”的辅助工具了？

黑暗浪子 写道

说到底你就是不想看代码。如果看代码，你的1根本不是问题。而2就说明了为什么你有1这个说法的原因。
个人认为如果是开发人员看代码肯定要比看注释更能理解整体。不过国内很多代码都比较混乱，因此造成用注释来补充说明的举动。
所以不写注释的前提就是写出简洁，高效，规范的优秀代码。脱离这个前提，不写注释当然是不可能的。

软件工程教科书？残念～
这还真不能细说。
JAVA标准包里的API或许可以看作是优秀代码的典范。当然由于历史悠久，它也有很完整的注释。
但是很多API其实根本不需要看它的注释就知道是派什么用处的，不是吗？

30 楼 ozzzzzz 2009-05-07  

chenjianjx 写道

拜托，你调用java标准包中的某个API之前会把整个方法的源代码看一遍？ 
如果不会，那你又凭什么要求你的同事细阅你的代码呢？
协同开发本来就是基于契约的嘛。好像我找你采购一批螺钉，我只需要知道你的规格就够了，难道我还要知道你是怎么淬火的？ 时间宝贵！

写注释，本来就是软件工程教科书上的理论，怎么在你眼里成了“补充混乱代码”的辅助工具了？

黑暗浪子 写道

说到底你就是不想看代码。如果看代码，你的1根本不是问题。而2就说明了为什么你有1这个说法的原因。
个人认为如果是开发人员看代码肯定要比看注释更能理解整体。不过国内很多代码都比较混乱，因此造成用注释来补充说明的举动。
所以不写注释的前提就是写出简洁，高效，规范的优秀代码。脱离这个前提，不写注释当然是不可能的。

请问你引用java标准包里面某个api的时候会看这个api的注释吗？

29 楼 chenjianjx 2009-05-07  

这样说也对。但更节省时间的做法是看JAVADOC，通过Eclipse就可以直接看到，而不用去找API的单元测试类。

daquan198163 写道

chenjianjx 写道

恰恰相反，自然语言的表达能力比JAVA语言的表义能力强得多。看到一个JAVA方法名，我们可能要猜它的意义；但看到一条英语句子，我们就会很明确了。 举个例子，在apache的StringUtils类中，如果你不看注释，你知道defaultString()是什么意思吗？你能百分百确定 isEmpty()和 isBlank()的区别吗？ 除了空格和制表符算一种“Blank”，回车换行算不算"Blank"呢？

看测试。
所以说“源代码是最好的文档”还不全面，应该是“源代码及其测试是最好的文档”。

28 楼 chenjianjx 2009-05-07  

拜托，你调用java标准包中的某个API之前会把整个方法的源代码看一遍？ 
如果不会，那你又凭什么要求你的同事细阅你的代码呢？
协同开发本来就是基于契约的嘛。好像我找你采购一批螺钉，我只需要知道你的规格就够了，难道我还要知道你是怎么淬火的？ 时间宝贵！

写注释，本来就是软件工程教科书上的理论，怎么在你眼里成了“补充混乱代码”的辅助工具了？

黑暗浪子 写道

说到底你就是不想看代码。如果看代码，你的1根本不是问题。而2就说明了为什么你有1这个说法的原因。
个人认为如果是开发人员看代码肯定要比看注释更能理解整体。不过国内很多代码都比较混乱，因此造成用注释来补充说明的举动。
所以不写注释的前提就是写出简洁，高效，规范的优秀代码。脱离这个前提，不写注释当然是不可能的。

27 楼 黑暗浪子 2009-05-07  

chenjianjx 写道

恰恰相反，自然语言的表达能力比JAVA语言的表义能力强得多。看到一个JAVA方法名，我们可能要猜它的意义；但看到一条英语句子，我们就会很明确了。 举个例子，在apache的StringUtils类中，如果你不看注释，你知道defaultString()是什么意思吗？你能百分百确定 isEmpty()和 isBlank()的区别吗？ 除了空格和制表符算一种“Blank”，回车换行算不算"Blank"呢？

ozzzzzz 写道

黑暗浪子 写道

最好的注释是代码，印象中是uncle Bob说的。
但是好像kent beck说最好的文档是代码。
所以，嘿嘿。
写代码这事情不能细说啊~

文字的东西很不可靠，因为无法测试，无法验证。是否同步就显得很不好验证。
比如你写了个注释，别人在这之后修改了代码，但是注释忘记了。测试也通过了，运行和部署都没有问题。但是过了之后，忽然出现了bug，你跟着注释一看，这块不应该有问题，放过的机会非常大。
而且我这个人私下认为，一个人写不好代码，希望他们写的注释和文档要能好，也是有点奢望。反正我见到的主要是能写好代码的，也能写好注释和文档，只不过他们不愿意写。
另外一个更加麻烦的事情是，以后SCM工具和CASE之类的东西，往往喜欢在注释里面添加点什么，而有的部署工具也喜欢在代码里面填东西。遇到这种情况十分难以控制最终究竟会发生什么问题。
同时你还会发现，自然文字的东西往往有多义性，特别是别人看的时候，产生错误理解的可能性很大。如果那个人刚好是一个跟上面这些不喜欢动脑筋，也不喜欢查资料的人所类似，那么后果就十分的不能被控制。
所以我十分反感在完成的代码中出现人手工写的和维护的注释。今天我再次重复一遍，但愿这个是最后一次了。

最近在看《clean code》，uncleBOB说“写代码的最高境界就是把代码写成一篇让人可以阅读的英语小文。”所以说应该是看到一个JAVA方法就像看到一段英语段落。而一个class就是一篇由几个段落组合而成的article。
而不是仅仅看方法名，有谁能看一篇文章的title就能知道这文章具体说什么吗？

26 楼 黑暗浪子 2009-05-07  

daquan198163 写道

chenjianjx 写道

恰恰相反，自然语言的表达能力比JAVA语言的表义能力强得多。看到一个JAVA方法名，我们可能要猜它的意义；但看到一条英语句子，我们就会很明确了。 举个例子，在apache的StringUtils类中，如果你不看注释，你知道defaultString()是什么意思吗？你能百分百确定 isEmpty()和 isBlank()的区别吗？ 除了空格和制表符算一种“Blank”，回车换行算不算"Blank"呢？

看测试。
所以说“源代码是最好的文档”还不全面，应该是“源代码及其测试是最好的文档”。

测试代码不是代码吗？
说道最后还是说明“源代码是最好的文档”这句话。
不过我个人对这句话持保留意见。

25 楼 黑暗浪子 2009-05-07  

chenjianjx 写道

Whatever they say, they say.

注释是对一个接口的说明，也就是说可以充当部分“契约”

如果我们不写注释
   1. 仅凭方法名和参数名未必能猜到详尽的契约。比如哪些参数Nullabe，这个API在整个框架中的作用等等。有个典型的例子就是java.util.Set。它有个约定就是它的元素应该实现hashCode()方法和equals()方法，Set将基于这两个方法来比较两个元素是否相等。

   2. 有人说看看代码细节也能明白方法的契约。但我只是要调用一个接口，我把你当一个黑盒，凭什么要求我花时间去看你的代码实现？

黑暗浪子 写道

最好的注释是代码，印象中是uncle Bob说的。
但是好像kent beck说最好的文档是代码。
所以，嘿嘿。
写代码这事情不能细说啊~

说到底你就是不想看代码。如果看代码，你的1根本不是问题。而2就说明了为什么你有1这个说法的原因。
个人认为如果是开发人员看代码肯定要比看注释更能理解整体。不过国内很多代码都比较混乱，因此造成用注释来补充说明的举动。
所以不写注释的前提就是写出简洁，高效，规范的优秀代码。脱离这个前提，不写注释当然是不可能的。

24 楼 daquan198163 2009-05-07  

chenjianjx 写道

恰恰相反，自然语言的表达能力比JAVA语言的表义能力强得多。看到一个JAVA方法名，我们可能要猜它的意义；但看到一条英语句子，我们就会很明确了。 举个例子，在apache的StringUtils类中，如果你不看注释，你知道defaultString()是什么意思吗？你能百分百确定 isEmpty()和 isBlank()的区别吗？ 除了空格和制表符算一种“Blank”，回车换行算不算"Blank"呢？

看测试。
所以说“源代码是最好的文档”还不全面，应该是“源代码及其测试是最好的文档”。

23 楼 chenjianjx 2009-05-07  

恰恰相反，自然语言的表达能力比JAVA语言的表义能力强得多。看到一个JAVA方法名，我们可能要猜它的意义；但看到一条英语句子，我们就会很明确了。 举个例子，在apache的StringUtils类中，如果你不看注释，你知道defaultString()是什么意思吗？你能百分百确定 isEmpty()和 isBlank()的区别吗？ 除了空格和制表符算一种“Blank”，回车换行算不算"Blank"呢？

ozzzzzz 写道

黑暗浪子 写道

最好的注释是代码，印象中是uncle Bob说的。
但是好像kent beck说最好的文档是代码。
所以，嘿嘿。
写代码这事情不能细说啊~

文字的东西很不可靠，因为无法测试，无法验证。是否同步就显得很不好验证。
比如你写了个注释，别人在这之后修改了代码，但是注释忘记了。测试也通过了，运行和部署都没有问题。但是过了之后，忽然出现了bug，你跟着注释一看，这块不应该有问题，放过的机会非常大。
而且我这个人私下认为，一个人写不好代码，希望他们写的注释和文档要能好，也是有点奢望。反正我见到的主要是能写好代码的，也能写好注释和文档，只不过他们不愿意写。
另外一个更加麻烦的事情是，以后SCM工具和CASE之类的东西，往往喜欢在注释里面添加点什么，而有的部署工具也喜欢在代码里面填东西。遇到这种情况十分难以控制最终究竟会发生什么问题。
同时你还会发现，自然文字的东西往往有多义性，特别是别人看的时候，产生错误理解的可能性很大。如果那个人刚好是一个跟上面这些不喜欢动脑筋，也不喜欢查资料的人所类似，那么后果就十分的不能被控制。
所以我十分反感在完成的代码中出现人手工写的和维护的注释。今天我再次重复一遍，但愿这个是最后一次了。