尽管需要注释，但是我们尽量减少注释
与其花时间为那些糟糕的代码写注释，还不如花时间好好清理那些糟糕的代码
很多时候代码就可以解释我们大部分的意图
比方这样的代码：
你愿意看到这个？ if (info.gender == FEMALE && info.age == ADMIN) 还是这个？ if (info.isFemaleAdmin())我们只需要创建一个描述与注释所言同一事物的函数即可
唯一真正好的注释就是你不写注释
不需要把所有法律条款放到注释中，指向一份标准许可或者是外部文档即可
不过这里我们平时开发基本不会涉及到
其实一般也不用，用函数名表达出来就可以了，除非特别复杂
书中所示的代码是，写代码的人注释自己的代码是能想到的最好的办法
我理解为：在代码中对你觉得不太完美的解决方案的地方进行注释
我个人觉得能想明白尽量还是不要阐释代码，比如说魔法值的问题，有很多人写代码不喜欢写常量，经常是00 01代表什么什么，然后来一个阐释的注释，这样是很不好的习惯。代码中将会出现大量这样的注释，而且我们还会冒着注释可能过时的风险。
对于可能出现别人看不懂的地方，或者你认为容易出问题的地方我们可以给出警告
有时需要用todo来表示我们未完成的工作，但是应该及时删除没用的todo注释
注释可以放大某种不合理之物的重要性
如果你是在编写公共api，我们很有必要写一个有良好描述的注释了，尤其是会被经常调用的方法
大多数注释都是属于此类，糟糕代码的借口，错误决策的修正，基本上都是程序员自说自话
不要自说自话，为了安慰自己而写，有时候说出来可能别人都看不懂
不要写那些废话，尤其是给方法写注释，我突然想起我刚刚入行的时候，每个方法每个变量都写了注释，连请求网络的方法都要写一个javadoc来说明这是在请求网络，那时候还感觉自己特别敬业，特别认真，其实都是在搞笑
这个不说了，不要写误导的注释，尤其是我们在修改代码后没有改注释，这样就变成了代码之前状态的注释，误导其他人
和我上面说的一样，要求每个方法都有javadoc注释是很愚蠢的行为
不要在模块上加你什么什么时候修改，改了什么东西，这又不是修订记录，没有必要，只会让看到他的人更加的崩溃
明明某个变量和方法已经告诉你是干什么的，就不需要再通过注释说明它们是什么了
有时候注释会写的跟变量名和方法名一样，这样太可笑了
作者举了个例子，有时候我们为了省去局部变量的声明，将很复杂的几行代码缩短为一行，这样会降低代码的可读性，然后不得不去写一些注释，我们应该去把控粒度，明确到底如何去将注释转化到代码中去
在我之前写代码的时候，比如遇到了一个Activity写了很大的时候，回去搞一个标记，上面是在初始化控件，中间的是网络请求，下面的是什么什么，还用注释标记着，整个一行还打着横线。上下空了好几行，觉得这样把一个Activity划分的很细致，还沾沾自喜，后来想想确实也是挺搞笑的。如果真的有必要使用的时候，可以酌情使用，但是不要滥用
这个不用说了吧我觉得，注释一般都是在上一行写，我没干过这事
我们需要为我们所创建的代码写上作者和日期
我一般会下意识的去这样想：这个东西是你创造的，你要对它负责，请注意自己的代码质量
一般开发工具可以设置，在你创建类的时候自带作者名字和创建时间
注释掉的代码就删了吧
其实大部分犯难的时候是需求在快速变化的时候，老板在琢磨不定的时候，我们害怕或许哪一天老板又回到上次的那种状态呢
这就需要我们根据实际情况去考虑了
一般不建议给HTML做注释
写注释要确保描述的是离它最近的代码
别在注释中添加其他没用的历史性话题，或者去瞎扯淡
注释如果还需要再解释，那这写的是什么注释
段函数一般不用写注释，好的函数名就可以说明一切
不是公共代码中的方法其实也没必要写javadoc了
我们应该知道什么样的注释是必要的，什么样的注释是废话
并不是越详细的注释越好，有时候太详细了会给读者造成一定的困难
刚入行时总认为写注释是一个好习惯，写出详细的注释更是有责任心和对代码负责的表现
其实我们一定要注意变量和函数的命名，减少注释
在合适的情况合适的时机下去写出可以在日后帮助到你和其他开发者的注释
在注释这一块，不要让别人看到你对于注释的处理就像个傻子一样
