代码注释问题

Question

几个人一起写一个小项目时，需要代码的注释，往往代码会写，明白那个意思，注释却写不出来，有没有什么办法能让我解决这个问题，注释代码很是头疼

Answer 1

在多人合作开发的时候写注释要养成好习惯，比如：1.如果你要在原先的代码中添加你写的新的代码，那么就这样写：//add  2016-11-7   by  谁    添加了什么功能   start具体的代码//add  2016-11-7   by  谁    添加了什么功能    end2.如果你要在原先的代码中进行修改，那么就这样写：//mod  2016-11-7   by  谁    因为哪里有问题，所以你修改了   start具体的代码//mod  2016-11-7   by  谁     因为哪里有问题，所以你修改了   end3.如果你发现原先的部分代码有问题，要注释掉，那么就这样写：//注释  2016-11-7   by  谁    哪里有问题，为什么注释    start具体的代码//注释  2016-11-7   by  谁    哪里有问题，为什么注释    end

Answer 2

我看到某个培训学校老师的“例子”，它们1000行代码中恨不得有500行注释。如果这是想描述实际的大项目，“我cao”这是多么恶心的事情啊。1000行代码中有50行代码有具体注释，通常就足够了。1000行代码可能用3天写完，而它需要花2个月时间来研究、分析、设计几种文档，需要写一本（100页）的文档并且打印出来，并且反复开会宣讲几次，代码要重构几十次，要把2000行代码中的垃圾删减掉最后剩下1000行。最后经过几万次测试。这才叫软件工程。这样的代码，有几十行注释，最精当。

Answer 3

注释多少并没有定量，看情况吧。去看看.NET源代码，注释非常多。

Answer 4

注释写多少和注释写不出来，这两个问题是不同的。要解决注释写不出来，我觉得可以学些下.NET源码。

Answer 5

1. 一个大项目， 最好有个总体规划的流程图或类似的文档， 这个比一般的注释更有效果， 一图胜万言;2. 代码本身就应该有自解释性, 如： GetById, GetList……3. 注释原则：
如果这段代码， 不写注释， 离开一年之后看不明白， 那就应该写。
反之， 就没太大必要。大的项目往往代码繁多， 至少在参数比较多、难以理解、比较复杂的一些方法上要做注释， 其它的写不写注释关系不大。