你写注释吗？

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

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

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

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

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

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

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

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

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

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

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

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