/* a = b+c; /* 注释 */ */
我的手抬了抬，终究作罢。虽然我感觉到尊严被践踏，心爱的作品被蹂躏，但我还是开始反思。许多软件规范、专家、有经验的工程，都建议或要求注释代码最好使用/**/，他们的理由大略如下:
1 "//"进行注释不够严谨
例如:
// 注释语句 ??/a = b+c;
此时，a = b+c在一些编译器不会被执行。因为"??/"会被编译器当作 \，变成C语言的换行符。于是这段代码等同于// 注释语句 a = b+c ;就会被注释掉。大家有兴趣的，不妨去搜索一下"C语言 三字母词"当然，哪怕没有??/， 自己打盹碰到delete键也是会屏蔽掉a=b+c的。
2 "//"的注释来源于C++
有些早期的C编译器对这种注释是不支持的。代码要做到全平台兼容，这点是必须要考虑的。因此，老外定义的C语言软件规范，无论是MISRA还是CMMI，一般都要求所有代码注释必须使用/**/。君不见，那uCOS的最新版本源码，所有注释都是/**/。君不见，那STM32的最新固件库，洋洋洒洒几十个文件，通篇皆没有用到//。正是基于这样的理由，让我的心中充满了愠怒。但我仍然没有当场反驳她，因为这些理由还有些苍白无力。当时，那个什么三字母词“??x”到底是什么我已经忘了，没法立刻做试验编译给她看，而且时候我里面做了编译实验，得到的是："filename.c", line xxxx: Warning: #2532-D: support for trigraphs is disabled xx代码语句xx // ??/trigraph金山词霸---> [traigra:f]三字母词，看吧，编译器都警告了，默认是不支持的。而且，所谓的//是C++的，早期的c编译器不支持。这点谁鸟啊，我们只要现在，只用最新版本的编译器，所以，我还要继续思考，我要维护这个传统，为自己代言......我开始思考，还有什么强劲有力的理由，来支持我恪守的真理：C语言代码注释必须使用/**/。
3 我的三大理解
倘若所有代码里面的注释用到/**/时，当你要注释掉这段代码时，如果不想忍受编译器的嵌套报警，又懒得把一个个/**/换成//的话。那么你还有如下选择。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”是一个如此的醒目，很容易成为一个评估软件质量、工作绩效的搜索关键词。从管理的角度，这个是可以量化的。因此，理由三: 使用/**/注释代码，有利于公司进行软件质量控管，对程序员绩效考核。这三个理由，足够说服你么？
0
