注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败。我们总无法找到不用注释就能表达自我的方法，所以总要有注释，这并不值庆贺。
如果你发现自己需要写注释，再想想看是否有办法翻盘，用代码来表达。
注释会撒谎。注释存在的时间越久，就离其所描述的代码越远，可能变得全然错误。原因很简单：程序员不能坚持维护注释。
程序员应当负责将注释保持在可维护、有关联、精确的高度。我同意这种说法。但我更主张把力气用在写清楚代码上，直接保证无须编写注释。
真实只在一处地方有：代码。只有代码能忠实地告诉你它做的事，所以应当减少注释。
写注释的常见动机之一是糟糕的代码的存在。我们编写一个模块，发现它令人困扰、乱七八糟。我们告诉自己：最好写点注释。不！最好是把代码弄干净!
比如 if ( (dataType>>24) &0x0f == 1)
dataBits = 24; //Color
else if (dataType>>24 & 0x0f == 2)
dataBits = 8; //Grayscale
else
dataBits = 1;//Black and White
就可以改为:
colorType = (dataType>>24)&0x0f;
switch(colorType)
{
case COLOR:
dataBits = 24;
case GRAYSCALE:
dataBits = 8;
case BLACK_WHITE:
default:
dataBits = 1;
}
TODO注释一定要定期查看，删除不再需要的，不然可能会变成一堆垃圾。
坏注释
1.自言自语
自己为标注某些未完成工作所加的注释。
2. 外余的注释
有时注释读起来比读代码还费劲。比如MicroSoft提供的一些例程,有时还不如先看MSDN。
3. 误导性注释
4.循规式注释
为所有函数和变量都加上Doxygen格式的注释显然不是什么好主意。
5. 日志式注释
使用SVN之类的版本控制软件更为合理。
6. 废话注释
比如
/**
* Default constructor
*/
MyClass::MyClass()
{
......
}
7.代码中的签名
8. 注释掉的代码