我开始思考，还有什么强劲有力的理由，来支持我恪守的真理：c语言代码注释必须使用/**/.
有的！
倘若所有代码里面的注释用到/**/时，当你要注释掉这段代码时，如果不想忍受编译器的嵌套报警，又懒得把一个个/**/换成//的话。那么你还有如下选择。
1) 慎重思考下是否删光这段代码，如果还有些不舍，那就先"备份"(git推送)一下再删光。因此，
理由一：使用/**/注释代码，会使软件系统减少冗余的僵尸代码，鼓励程序员的程序备份行为。
2) 或者用编译条件圈起来，如下。
- #if (XXX_ENABLE)
- func(a, b, c); /* 注释 */
- ...... /* 注释 */
- #endif
那么你不得不考虑xxx的命名，如何更加一目了然，再写点注释什么的，表明对这段代码“弃而不舍”的缘由。因此，
理由二：使用/**/注释代码，会鼓励程序员删除代码时，三思而后行，并且注明舍弃的理由。
3) 当然，偷懒的人还是会用 #if 0 #endif圈起来， 如下，
- #if 0
- func(a, b, c); /* 注释 */
- ...... /* 注释 */
- #endif
而且，不会写任何注释表明删除的理由。然而，“#if 0”是一个如此的醒目，很容易成为一个评估软件质量、工作绩效的搜索关键词。从管理的角度，这个是可以量化的。因此，
理由三: 使用/**/注释代码，有利于公司进行软件质量控管，对程序员绩效考核。
这三个理由，足够为自己代言吗？
用户404269 2014-1-5 17:28
用户439555 2014-1-2 15:32
用户1406868 2014-1-1 19:04
用户1639872 2013-12-25 00:35
用户1406868 2013-12-24 12:32
那是你们没有规定好编码规范。 另外 即便没有编码规范，就因为这个 你还折腾这么久 我觉得你们就是闲的
allen_zhan_752827529 2013-12-24 11:44
理论上你是正确的, 我支持你. 实际的使用上, 支持合并您的代码的那位工程师, 在我的代码中, 极少见 /**/, 理由同那位工程师. 特别在移植例程代码, 进行逐行逐段或全文件屏蔽, 分析调试功能, /**/ 导致工作量急剧增加. 我的 /**/ 几乎只用于文件头部的 description, including purpose, funcitons, author, email, written time or modified time, history, as so on. So it just is different for the coders' style, never mind.
用户1639928 2013-12-24 10:56
用户1602177 2013-12-24 10:20
用户1639872 2013-12-22 00:09