您还没有登录,请您登录后再发表评论 相关推荐
-
JVM类装载器详解
JVM类装载器详解
-
JVM类装载器机制
加载：查找并加载类全限定名的二进制字节流，转为方法区数据结构（特殊的堆），在Java堆中生成对应的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。 注意：对于数组类，情况就有所不同，数组类本身不...
-
java类验证和装载顺序_一张图看懂JVM之类装载系统
原标题：一张图看懂JVM之类装载系统 导读在之前的文章中，我们通过一张图的方式(图????)整体上了解了JVM的结构，并重点讲解了JVM的内存结构、内存回收算法及回收器方面的知识。收到了不少读者朋友们的反馈和指正，在...
-
JVM类加载器（类装载子系统）
加载:通过类的全限定名获取此类的字节流,将流代表的静态存储结构转化为方法区(作为一个内存区域,jdk1.7以前永久代,1.8之后元空间)的运行时数据结构,在内存中生成一个代表该类的java.lang.class对象,作为方法区这个类...
-
JVM之类装载子系统
如果一个类是用户类加载器加载的，JVM会将类加载器的引用作为类的一部分信息保存在方法区当中，当解析一个类型到另一个类型引用的时候，JVM则必须保证两个类加载器是相同的。（动态链接） JVM中对类的使用分为主动和...
-
JVM系列之三：类装载器子系统
虚拟机类装载器子系统：虚拟机把描述类的数据从class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型。 类的加载指的是将类的.class文件中的二进制数据读入到...
-
JVM类加载器子系统
JVM Class Loader SubSystem概述类加载的过程加载阶段(Loading)链接阶段(Linking)初始化阶段(Initialization)3种类加载器& 自定义加载器获取 ClassLoader的4种方式自定义类加载器(User Defined ClassLoader)双亲...
-
JVM学习笔记02-类加载器子系统
1、类加载器子系统的作用 2、类加载器ClassLoader角色 3、类的加载过程 3.1、加载 3.2、链接 4、类加载器的分类 4.1、引导类加载器（Bootstrap ClassLoader） 4.2、扩展类加载器（Extension Class Loader） ...
-
JVM(二)类装载子系统
类加载器子系统负责从文件系统或者网络中加载Class文件，class文件在文件开头有特定的文件标识。 ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine(执行引擎)决定。 加载的类信息存放于...
-
JVM—类加载子系统
类加载器执行引擎在Java的日常应用程序开发中，类的加载几乎是由上述3种类加载器相互配合执行的，在必要时，我们还可以自定义类加载器，来定制类的加载方式。为什么要自定义类加载器？隔离加载类修改类加载的方式...
-
JVM类加载子系统
类加载器子系统负责从文件系统或者网络中加载Class文件，class文件在文件开头有特定的文件标识。 ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine(执行引擎)决定。 加载的类信息存放于...
-
[JVM]超详细JVM系列文（1）：整体结构+类加载子系统+运行时数据区—程序计数器、栈（多图长文）
按照Java代码执行的流程，从类装载器子系统出发，剖析其各个子模块的结构与功能。结合Java语言中的相关设计思路（变量的初始化、存储；对象的生命周期、方法的调用）、OOP（继承、多态），在JVM进行追根溯源，解释其...
-
JVM一：类加载器子系统
类加载器子系统（ClassLoader）：将class字节码文件加载到JVM内存中,是否会执行该字节码文件由 执行引擎决定。 类加载器子系统（Class loader subSystem）只负责将class文件加载进内存中，并且类在仅需要时加载，...
-
【JVM】VM是什么？JVM是什么？JVM作用是什么？JVM特点？JVM位置？JVM组成？
1、类加载子系统类加载的角色？类加载的过程？① 加载 Loading② 链接 Linking③ 初始化 Initialization类什么时候初始化？类的初始化顺序？类加载器分类？双亲委派机制是什么？双亲委派的优点？类的主动使用/被动...
-
JVM第二章-类加载子系统
类加载器子系统负责从文件系统或者网络中加载Class文件，class文件在文件开头有特定的文件标识。 ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine决定。 加载
-
JVM-类加载子系统
System . out . println("你的大恩大德，我下辈子再报！");} }它的加载过程是怎么样的呢?...完成后调用 HelloLoader 类中的静态方法 main加载失败则抛出异常完整流程JVM严格来讲支持两种类型的类加载器。...
-
JVM总结之类加载子系统
一个类的完整生命周期如下 类加载过程 Class 文件需要加载到虚拟机中之后才能运行和使用，那么虚拟机是如何加载这些 Class 文件呢？ 系统加载 Class 类型的文件主要三步：加载->连接->初始化。连接过程又...
-
JVM系列之类加载子系统
1、类加载器与类的加载过程 1.1、类加载器 1.1.1、类加载器子系统的作用 负责从文件系统或者网络中加载Class文件，class文件在文件开头有特定的文件标识，魔术，CA FA BA BE Classloader只负责class文件的加载，...
-
4. JVM-类加载子系统
类加载器子系统负责从文件系统或者网络中加载Class文件，class文件在文件开头有特定的文件标识。 ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine决定。 加载的类信息存放于一块称为...
-
【JVM】类加载子系统
一，内存结构 二，类加载器及类加载过程 三，类加载器的分类 四，ClassLoader的常用方法及获取方式 五，双亲委派机制 六，其他
55 楼 kidneyball 2012-11-23 09:19
我明白你的意思，你就是想碰到问题后一行行的看代码来解决。
这有什么问题吗？不但一行行看，还要看前后两级以上的调用关系。顺便还重构一下，删掉一些过期（没闲功夫改，如果注释过期了与其放着误导人，干脆删掉）或者不必要的注释。
54 楼 phk070832 2012-11-23 09:10
恰恰相反
我非常认同“优秀的程序不需要加以说明；糟糕的程序需要大量注释。”
如果一段代码：
变量命名规范
方法名见名知意
方法粒度合适（功能专一、健壮）
格式化良好
我认为是不需要注释的，至少在方法内部是不需要注释的。除非读者的英语水平很差、或者没学过编程。
您说得内几点, 是个正常点的程序员都做得到. 注释的目的是让人家看懂整个过程中如何处理或实现复杂的业务逻辑.
这是要干什么啊？几千行的类？COBOL吗？
需要几千行吗？假设有一段50行的代码，如果根据注释发现这段代码跟你需要解决的问题无关，你就完全可以跳过，这样你每次看代码都可以节省时间。
解决问题的时候，如果操作得当（由异常位置反推），怎么会跑到无关的地方去。如果你跟着逻辑链跑到一个类里，一看注释，嗯，跟要解决的问题无关，不看。查了一天发现问题就在这里，再排查半天，某人跟你道个谦：哦，不好意思，改了程序忘了改注释。你找谁哭去。
你想的太理想化了，如果一个方法有100行，其中出问题的代码在51行，那么如果你能够根据注释直接看第51行的代码不是能节省时间吗？而且一个系统大了是很复杂的（而且改的人多了，肯定会存在很多不规范、重复的地方）。
另外你怎么知道你所谓的逻辑链，所有的代码都是你开发的，还是你事先就看过所有的代码。
抚心自问一下，你有多少次在bug时试过因为注释令你能刚好精确定位到你一行本来看不懂的代码（如果本来就能看懂就跟注释没关系了），然后就根据注释的给你的启示修改了这行代码，刚好把你的bug改对了，还刚好没有引入其他问题，最后你还细致地修改了注释，让后面的人能根据注释理解你的改动。
逻辑链就是从你发现异常（包括抛出异常或者结果与预期不符）的地方开始，层层倒推，看看这个结果是怎么来的。从哪里开始与预期不符。这个过程中，注释有可能帮上忙的地方就是给你点提示，让你更容易判断预期值。不过这类判断，从变量或函数命名，前后附近的一些逻辑去判断更为准确，毕竟如果一个程序员连变量名都不好好写，你怎么能相信他会好好写注释。连能测试，一直在维护的程序都出错了，你怎么能相信这里写的注释没有错，具有时效性？
这个过程中，真正有效地注释就是TODO类的，让你知道某个功能或者某种分支其实还没处理，别人用的时候以为他已经处理了导致出错。还有就是记录为何采用某些非常规做法的，让你不会因为考虑不周把它改回常规做法，而没有考虑到当初别人已经想过的问题。其他的信息可以从命名和程序结构，还有提交记录的Annotation来获取。这些信息如果有问题，通常都可以追朔到编写人的责任，所以相对可信。
我明白你的意思，你就是想碰到问题后一行行的看代码来解决。
53 楼 hlylove 2012-11-22 21:52
个人认为业务场景还要要说明的。
而且这篇明显就是老外写的，英语是人家的母语，我们很多程序员命名都是金山词霸出来了，词不达意，或者歧义的情况时有发生，该写注释的时候还是要写的。
算是看见有靠谱的了。
52 楼 wushexu 2012-11-22 13:25
无法想像让一个新手来维护一个大型系统的核心代码，这样的代码也不应该为照顾新手而写注释（你也照顾不了）
（想像一下一个邮箱客户端应用的代码里尽是关于TCP/IP、SSL、SMTP、POP原理和规范的注释）
51 楼 wushexu 2012-11-22 12:45
1. TODO和FIXME
2. 在一些非常规的做法上说明为什么没有采用常规做法（以防后面忘了原因，又改回常规方法了）
3. 在临时注释掉的代码之前说明为什么要注释掉
其他在主线流程上的注释，看了不如不看。
有人说，那我想说明某段代码对应哪个业务需求怎么办。正确做法是，每次只提交跟某个业务需求相关的修改，认真写好提交信息，这样从版本控制的Annotation上就能清清楚楚看到每一行代码时对应哪个需求的。
同意。见我上一条
50 楼 wushexu 2012-11-22 12:43
如果代码写得很漂亮（设计好、逻辑清晰、各种名起得好），有没有注释都很很漂亮。如果代码写的很恶心，注释会让恶心加倍。
我写的核心代码，如果某人没有注释就看不懂（如果这样，有注释我怀疑他也看不懂），我就不要他参与。他只能做简单的CURD维护，做核心只会越做越烂。
49 楼 kidneyball 2012-11-22 10:59
“由异常位置反推” 很多错误都不会导致异常的，这种方式只能解决最简单、最表层的问题。
好吧，这是自然语言歧义的又一个好例子。我说的“异常”，是“异于正常的情况”，包括结果与预期不符。你理解的“异常”，是“Exception及其子类”。在注释里这类误解处处可见。
48 楼 kidneyball 2012-11-22 10:53
恰恰相反
我非常认同“优秀的程序不需要加以说明；糟糕的程序需要大量注释。”
如果一段代码：
变量命名规范
方法名见名知意
方法粒度合适（功能专一、健壮）
格式化良好
我认为是不需要注释的，至少在方法内部是不需要注释的。除非读者的英语水平很差、或者没学过编程。
您说得内几点, 是个正常点的程序员都做得到. 注释的目的是让人家看懂整个过程中如何处理或实现复杂的业务逻辑.
这是要干什么啊？几千行的类？COBOL吗？
需要几千行吗？假设有一段50行的代码，如果根据注释发现这段代码跟你需要解决的问题无关，你就完全可以跳过，这样你每次看代码都可以节省时间。
解决问题的时候，如果操作得当（由异常位置反推），怎么会跑到无关的地方去。如果你跟着逻辑链跑到一个类里，一看注释，嗯，跟要解决的问题无关，不看。查了一天发现问题就在这里，再排查半天，某人跟你道个谦：哦，不好意思，改了程序忘了改注释。你找谁哭去。
你想的太理想化了，如果一个方法有100行，其中出问题的代码在51行，那么如果你能够根据注释直接看第51行的代码不是能节省时间吗？而且一个系统大了是很复杂的（而且改的人多了，肯定会存在很多不规范、重复的地方）。
另外你怎么知道你所谓的逻辑链，所有的代码都是你开发的，还是你事先就看过所有的代码。
抚心自问一下，你有多少次在bug时试过因为注释令你能刚好精确定位到你一行本来看不懂的代码（如果本来就能看懂就跟注释没关系了），然后就根据注释的给你的启示修改了这行代码，刚好把你的bug改对了，还刚好没有引入其他问题，最后你还细致地修改了注释，让后面的人能根据注释理解你的改动。
逻辑链就是从你发现异常（包括抛出异常或者结果与预期不符）的地方开始，层层倒推，看看这个结果是怎么来的。从哪里开始与预期不符。这个过程中，注释有可能帮上忙的地方就是给你点提示，让你更容易判断预期值。不过这类判断，从变量或函数命名，前后附近的一些逻辑去判断更为准确，毕竟如果一个程序员连变量名都不好好写，你怎么能相信他会好好写注释。连能测试，一直在维护的程序都出错了，你怎么能相信这里写的注释没有错，具有时效性？
这个过程中，真正有效地注释就是TODO类的，让你知道某个功能或者某种分支其实还没处理，别人用的时候以为他已经处理了导致出错。还有就是记录为何采用某些非常规做法的，让你不会因为考虑不周把它改回常规做法，而没有考虑到当初别人已经想过的问题。其他的信息可以从命名和程序结构，还有提交记录的Annotation来获取。这些信息如果有问题，通常都可以追朔到编写人的责任，所以相对可信。
个人认为，注释应该在必要的地方记录“没做的”和“不做的”。而不是把那些本来通过程序自身已经能传达的信息，为了让人“好理解”又用自然语言写一次。或者说以为写了注释，程序自身就不需要关注别人是否能看懂。到最后只会增加维护的负担。
47 楼 kidneyball 2012-11-22 10:36
恰恰相反
我非常认同“优秀的程序不需要加以说明；糟糕的程序需要大量注释。”
如果一段代码：
变量命名规范
方法名见名知意
方法粒度合适（功能专一、健壮）
格式化良好
我认为是不需要注释的，至少在方法内部是不需要注释的。除非读者的英语水平很差、或者没学过编程。
您说得内几点, 是个正常点的程序员都做得到. 注释的目的是让人家看懂整个过程中如何处理或实现复杂的业务逻辑.
这是要干什么啊？几千行的类？COBOL吗？
需要几千行吗？假设有一段50行的代码，如果根据注释发现这段代码跟你需要解决的问题无关，你就完全可以跳过，这样你每次看代码都可以节省时间。
解决问题的时候，如果操作得当（由异常位置反推），怎么会跑到无关的地方去。如果你跟着逻辑链跑到一个类里，一看注释，嗯，跟要解决的问题无关，不看。查了一天发现问题就在这里，再排查半天，某人跟你道个谦：哦，不好意思，改了程序忘了改注释。你找谁哭去。
你想的太理想化了，如果一个方法有100行，其中出问题的代码在51行，那么如果你能够根据注释直接看第51行的代码不是能节省时间吗？而且一个系统大了是很复杂的（而且改的人多了，肯定会存在很多不规范、重复的地方）。
另外你怎么知道你所谓的逻辑链，所有的代码都是你开发的，还是你事先就看过所有的代码。
抚心自问一下，你有多少次在bug时试过因为注释令你能刚好精确定位到你一行本来看不懂的代码（如果本来就能看懂就跟注释没关系了），然后就根据注释的给你的启示修改了这行代码，刚好把你的bug改对了，还刚好没有引入其他问题，最后你还细致地修改了注释，让后面的人能根据注释理解你的改动。
逻辑链就是从你发现异常（包括抛出异常或者结果与预期不符）的地方开始，层层倒推，看看这个结果是怎么来的。从哪里开始与预期不符。这个过程中，注释有可能帮上忙的地方就是给你点提示，让你更容易判断预期值。不过这类判断，从变量或函数命名，前后附近的一些逻辑去判断更为准确，毕竟如果一个程序员连变量名都不好好写，你怎么能相信他会好好写注释。连能测试，一直在维护的程序都出错了，你怎么能相信这里写的注释没有错，具有时效性？
这个过程中，真正有效地注释就是TODO类的，让你知道某个功能或者某种分支其实还没处理，别人用的时候以为他已经处理了导致出错。还有就是记录为何采用某些非常规做法的，让你不会因为考虑不周把它改回常规做法，而没有考虑到当初别人已经想过的问题。其他的信息可以从命名和程序结构，还有提交记录的Annotation来获取。这些信息如果有问题，通常都可以追朔到编写人的责任，所以相对可信。
46 楼 phk070832 2012-11-22 09:46
恰恰相反
我非常认同“优秀的程序不需要加以说明；糟糕的程序需要大量注释。”
如果一段代码：
变量命名规范
方法名见名知意
方法粒度合适（功能专一、健壮）
格式化良好
我认为是不需要注释的，至少在方法内部是不需要注释的。除非读者的英语水平很差、或者没学过编程。
您说得内几点, 是个正常点的程序员都做得到. 注释的目的是让人家看懂整个过程中如何处理或实现复杂的业务逻辑.
这是要干什么啊？几千行的类？COBOL吗？
需要几千行吗？假设有一段50行的代码，如果根据注释发现这段代码跟你需要解决的问题无关，你就完全可以跳过，这样你每次看代码都可以节省时间。
解决问题的时候，如果操作得当（由异常位置反推），怎么会跑到无关的地方去。如果你跟着逻辑链跑到一个类里，一看注释，嗯，跟要解决的问题无关，不看。查了一天发现问题就在这里，再排查半天，某人跟你道个谦：哦，不好意思，改了程序忘了改注释。你找谁哭去。
恰恰相反
我非常认同“优秀的程序不需要加以说明；糟糕的程序需要大量注释。”
如果一段代码：
变量命名规范
方法名见名知意
方法粒度合适（功能专一、健壮）
格式化良好
我认为是不需要注释的，至少在方法内部是不需要注释的。除非读者的英语水平很差、或者没学过编程。
您说得内几点, 是个正常点的程序员都做得到. 注释的目的是让人家看懂整个过程中如何处理或实现复杂的业务逻辑.
这是要干什么啊？几千行的类？COBOL吗？
需要几千行吗？假设有一段50行的代码，如果根据注释发现这段代码跟你需要解决的问题无关，你就完全可以跳过，这样你每次看代码都可以节省时间。
解决问题的时候，如果操作得当（由异常位置反推），怎么会跑到无关的地方去。如果你跟着逻辑链跑到一个类里，一看注释，嗯，跟要解决的问题无关，不看。查了一天发现问题就在这里，再排查半天，某人跟你道个谦：哦，不好意思，改了程序忘了改注释。你找谁哭去。
“由异常位置反推” 很多错误都不会导致异常的，这种方式只能解决最简单、最表层的问题。
45 楼 phk070832 2012-11-22 09:41
恰恰相反
我非常认同“优秀的程序不需要加以说明；糟糕的程序需要大量注释。”
如果一段代码：
变量命名规范
方法名见名知意
方法粒度合适（功能专一、健壮）
格式化良好
我认为是不需要注释的，至少在方法内部是不需要注释的。除非读者的英语水平很差、或者没学过编程。
您说得内几点, 是个正常点的程序员都做得到. 注释的目的是让人家看懂整个过程中如何处理或实现复杂的业务逻辑.
这是要干什么啊？几千行的类？COBOL吗？
需要几千行吗？假设有一段50行的代码，如果根据注释发现这段代码跟你需要解决的问题无关，你就完全可以跳过，这样你每次看代码都可以节省时间。
解决问题的时候，如果操作得当（由异常位置反推），怎么会跑到无关的地方去。如果你跟着逻辑链跑到一个类里，一看注释，嗯，跟要解决的问题无关，不看。查了一天发现问题就在这里，再排查半天，某人跟你道个谦：哦，不好意思，改了程序忘了改注释。你找谁哭去。
你想的太理想化了，如果一个方法有100行，其中出问题的代码在51行，那么如果你能够根据注释直接看第51行的代码不是能节省时间吗？而且一个系统大了是很复杂的（而且改的人多了，肯定会存在很多不规范、重复的地方）。
另外你怎么知道你所谓的逻辑链，所有的代码都是你开发的，还是你事先就看过所有的代码。
44 楼 kingxip 2012-11-21 18:34
43 楼 if(i!=我){} 2012-11-21 15:28
对的，我觉得注释的重要性远大于代码，毕竟你不能保证你写的代码以后的效率依然是最高。大家都让别人方便，自然维护就方便了。
笑话！注释的重要性大于代码？还远大于？还有上上一层的“3000多行的代码”，更是个笑话！
之前接过一个做一半的项目，最大一个类2000多行、一个方法300多行，各种标识，各种重复。最后业务层我删了1/2代码，而且完成了更多的功能。没怎么加注释，但没人敢说他看不懂。
永远记住一句话：设计大于实现，规则大于编码——远大于！
这句话是你瞎编的吧
绝对不瞎编，社保一卡通项目的信息采集入库工作，老数据比较乱
上面的说错了，不相干……
好，说的不明白我说明白些
设计大于实现：这句话意思是前期的设计工作的重要性大于后期的实现（编码），这不用再解释了吧，反面教材不胜枚举。
规则大于编码：在稍微复杂的项目中，制定好良好的命名规范、类行为规范可以最大程度上减少配置量（统配符轻松减少70%的配置）、提高结构的清晰度；再有适当的抽象，代码的重用性也会高很多。
如果一个人一个写法，到最后项目组每个人只能看懂自己写的东西，如果让项目组外的人维护，他会哭死，改个需求他要看好几种代码风格。
42 楼 if(i!=我){} 2012-11-21 15:12
对的，我觉得注释的重要性远大于代码，毕竟你不能保证你写的代码以后的效率依然是最高。大家都让别人方便，自然维护就方便了。
笑话！注释的重要性大于代码？还远大于？还有上上一层的“3000多行的代码”，更是个笑话！
之前接过一个做一半的项目，最大一个类2000多行、一个方法300多行，各种标识，各种重复。最后业务层我删了1/2代码，而且完成了更多的功能。没怎么加注释，但没人敢说他看不懂。
永远记住一句话：设计大于实现，规则大于编码——远大于！
这句话是你瞎编的吧
绝对不瞎编，社保一卡通项目的信息采集入库工作，老数据比较乱
41 楼 kidneyball 2012-11-21 13:37
当然前面有个兄弟说的赞同，如果是想让新人容易看懂代码，是需要一点注释，因为他们还没懂怎么读代码。
对于新人，与其给他看注释，还不如教会他认真写提交记录和充分利用版本控制工具的Annotation（或叫Blame）功能。一个最常见的例子是，有些IDE自作聪明，在每个新建的类前面都自动打上个“作者谁谁谁”的注释。javadoc里这个所谓Author的标签就是注释歧义的最好体现，在创建类时自动生成的注释，显然应该叫CreatedBy，除非你能规定并且保证所有改动过这个类的人都在Author后面签名，否则这个标签就有一定的误导性质。
由于这种歧义，新人看代码时最喜欢做的事情就是看到某一句不明白，就跑去找作者问。结果作者看半天才记起来，这句根本就不是他写的。其实只要在Eclipse里右键，Team -> Show Annotation，就能列出来每一句最后究竟是谁，什么时候写的，如果那人当初好好的写提交记录，也能看出来是为什么要这样写。
40 楼 kidneyball 2012-11-21 13:11
对的，我觉得注释的重要性远大于代码，毕竟你不能保证你写的代码以后的效率依然是最高。大家都让别人方便，自然维护就方便了。
笑话！注释的重要性大于代码？还远大于？还有上上一层的“3000多行的代码”，更是个笑话！
之前接过一个做一半的项目，最大一个类2000多行、一个方法300多行，各种标识，各种重复。最后业务层我删了1/2代码，而且完成了更多的功能。没怎么加注释，但没人敢说他看不懂。
永远记住一句话：设计大于实现，规则大于编码——远大于！
是吗？估计你那个类里边只是一些简单的业务逻辑处理吧，如果你要写一个框架或者抽取一些公用的模块出来，或者说你编写的代码移交给新手，请问你的代码该怎么来维护呢？写代码一直都要养成一个好的习惯，不管是写注释还是设计。况且在《重构》中提到，好的代码在一个方法中不应该超过50行代码。
新手喜欢注释是因为：1. 注释比程序容易看（自然语言，多亲切）；2.自以为如果因为注释出错导致自己浪费时间，不关他事（虽然通常顶头上司不会这样看）。 新手最喜欢干的事情，就是把一整个方法连同注释从这里复制到那里，然后把方法名字改掉，把方法里四分三的代码改掉，注释一个字都不动。
哦，原来做不做注释还能区分新手与熟手？
不是区分新手熟手，是说你把一堆写满注释的代码交给新手维护，新手当然高兴。但从“维护”的角度来看，对整个团队未必有好处。注释无法测试，无法消除歧义，没有人刻意去检查，甚至因为别人不维护注释而给你带来麻烦，你都没立场骂他。人家一天改20个bug，漏改了几句注释，你被他一句注释误导困住一天啥都没干，你看你的经理帮谁。我小时候就是被注释骗过好几次，现在倾向于不敢轻信任何内部注释，到最终还是要看代码。麻烦的是如果别人写了一堆注释，出于负责，改完代码还得去读一遍注释，用原文的语气改半天。如果你一定要说区分，或者可以说对注释的态度能区分是否有在良莠不齐的团队中工作的经验。
我说的是内部注释，API上作为文档，会形成代码提示的那些注释不算。因为在团队环境中这部分注释与实际不符很快就会有人发现，而且实现与文档不符，又不改文档，那责任显然在修改人上。这部分还是比较可信的。
39 楼 Mybeautiful 2012-11-21 13:05
当然前面有个兄弟说的赞同，如果是想让新人容易看懂代码，是需要一点注释，因为他们还没懂怎么读代码。
38 楼 java_user 2012-11-21 12:41
对的，我觉得注释的重要性远大于代码，毕竟你不能保证你写的代码以后的效率依然是最高。大家都让别人方便，自然维护就方便了。
笑话！注释的重要性大于代码？还远大于？还有上上一层的“3000多行的代码”，更是个笑话！
之前接过一个做一半的项目，最大一个类2000多行、一个方法300多行，各种标识，各种重复。最后业务层我删了1/2代码，而且完成了更多的功能。没怎么加注释，但没人敢说他看不懂。
永远记住一句话：设计大于实现，规则大于编码——远大于！
是吗？估计你那个类里边只是一些简单的业务逻辑处理吧，如果你要写一个框架或者抽取一些公用的模块出来，或者说你编写的代码移交给新手，请问你的代码该怎么来维护呢？写代码一直都要养成一个好的习惯，不管是写注释还是设计。况且在《重构》中提到，好的代码在一个方法中不应该超过50行代码。
新手喜欢注释是因为：1. 注释比程序容易看（自然语言，多亲切）；2.自以为如果因为注释出错导致自己浪费时间，不关他事（虽然通常顶头上司不会这样看）。 新手最喜欢干的事情，就是把一整个方法连同注释从这里复制到那里，然后把方法名字改掉，把方法里四分三的代码改掉，注释一个字都不动。
哦，原来做不做注释还能区分新手与熟手？
37 楼 java_user 2012-11-21 12:40
对的，我觉得注释的重要性远大于代码，毕竟你不能保证你写的代码以后的效率依然是最高。大家都让别人方便，自然维护就方便了。
笑话！注释的重要性大于代码？还远大于？还有上上一层的“3000多行的代码”，更是个笑话！
之前接过一个做一半的项目，最大一个类2000多行、一个方法300多行，各种标识，各种重复。最后业务层我删了1/2代码，而且完成了更多的功能。没怎么加注释，但没人敢说他看不懂。
永远记住一句话：设计大于实现，规则大于编码——远大于！
这句话是你瞎编的吧
36 楼 romi 2012-11-21 11:44