本篇文章主要介绍注释对代码的重要性，在开发工作中，我们都写过注释，但是因为是什么写的注释呢？
有解释代码意思的，有解释变量意思的，有的注释掉没用的代码。这些原因其实都是不好的习惯，和代码一样，注释也有好有坏，注释其实也是一种失败，因为只有当代码表达不出我们想要表达的意思的时候，我们通常会用注释来加强解释，而且在我们维护代码的时候，不一定能及时维护注释，错误的注释会给我们造成很大的干扰，据一个最简单的例子

privte String HTTP_DATE_REGEXP = "[SMTWF [a-z] {2}\\,\\s[0-9]{2}\\s [JFMASOND][a-z]{2}\\s"]+"[0-9] {4} \\s[0-9]{2}\\:[0-9]{2}\\:[0-9]{2}\\sGMT";
private Response response;
private FitNessContext context;
//Example: "Tue ,02 Apr 2003 22:18:45 GMT"

我相信最开始写这段代码的时候注释肯定是在HTTP_DATE_REGEXP声明的下面的，但是随着时间变长，修改代码的人在变化，注释和声明之间增加了其他的代码，以至于现在这个注释就是没有放在正确位置，会给我买呢查看代码的时候增加干扰。

注释不能美化糟糕的代码，如果想着写一段漂亮的注释来解释代码。还不如费心思研究怎么写好代码，让代码就能说明代码的意思。

当然也有好的注释，那么怎么来看一个注释是好的还是坏的？我们继续往下看。

好注释

1.法律信息

有的时候要在代码开头的时候用注释来表示一些法律信息，比如版权和著作权之类的声明。

2.提供信息的注释

比如抽象类的返回值用注释解释一下，但是如果返回值的命名比较准确其实也是可以不用注释的看个人习惯把。再比如说，写正则规则的时候傍边协商符号格式数据的注释也是可以的。这样会让复杂的正则表达式看起来更明了。

3.阐释

有的时候表示一些晦涩难懂的返回值什么用注释翻译成某种比较简单的形式

asserTure(a.compareTo(a)==0);//a == a
asserTure(a.compareTo(b)!=0);//a ! =b
asserTure(ab.compareTo(ab)==0);//ab==ab
asserTure(a.compareTo(b)==-1);//a<b
asserTure(aa.compareTo(ab)==-1);aa<ab

上面这段代码中，注释能让我们更加明确每行代码所表示的意思，如果这样的代码还有好多行，即使我们有注释看起来也容易眼晕，所以这么写的时候，考虑下是否还有更好的办法没有。

4.警示

// Don't run unless you
//have some time to kill
//在测试环境下使用

这种代码警示我们在运行的的要注意什么是要关闭的，什么是不能运行的

5.TODO

//TODO会解释这段代码目前还有什么是需要改进的，现在正在准备对这段代码作出什么样的改动，这段代码将来要实现什么样的功能。

6.公共API中的Javadoc

如果标准Java库中没注释，写Java就会变得很难。

坏注释

1.一些没有意义和多余的注释

没有意意就是在上下文环境中注释的意思完全不符合当前代码的意思。
多余的注释就是

//The day of month;
private int dayOfMonth;
//name
private String name;

本来代码已经说的很明确了，还要用注释来表达一下，这就很多余，

2.日志式注释

有的人习惯在代码头部增加，修改日志的注释，修改代码的署名，在很久以前这样做或许有道理，但是现在我们有git和svn这样的管理代码工具，完全不用这样做，所以这样的的注释应该全部删除。

3.位置标记

有时候我们喜欢用Actions //////////////////////这样的注释带标记某一个位置，这种标记栏尽量少用。如果代码里有很多这样的标记，看起来也会很乱的。

4.不要在括号后面写注释

在括号后面写注释，会让缩进结构看起来很乱，有的开发工具中如果括号后面有注释，那么当你想收缩括号的时候会失败。

5.注释掉的代码

有时候我们调整代码的时候会把没用的代码注释掉，可是时间长了我们自己，和别人看到后不知道这是干嘛的，但是还不敢删除，这样这些没用的代码会一直存在你的程序中。所以注释掉的代码马上删除。

6.注释过长

本来注释是用来让我们更明了理解代码的，但是注释的内容却又很多很多，看起来很不简单，就失去本来的意义了。