原创
一线研发之声 之 C代码注释引发的“血案 (一)
2013-12-23 16:21
4425
27
45
分类:
消费电子
我要无辜的坦白说，您遇到标题党了。
没有血案，但有些冲突。不是代码bug，我要讲注释风格。
这位看官，既然来了，且读且评吧。故事是真实的，如有雷同纯属巧合。
事情是这样的，有人离职，公司调我补缺。那个系统一直有个工程师在维护，参与该系统的新人来了又走，他始终泰若磐石。刚过去一个礼拜，我就心下窃吼：“TMD坑爹啊！”，也彻底体会到什么叫---绝对的权威、专家。该软件系统，是公司发家的支柱产品，涉及十几个国家x七八个机型，700+个文件(C语言，所有.c .h档)，十几万行代码，尽两百个跨模块全局变量，编译条件成百上千......(好吧，这是找借口、吐槽的节奏)
尽管有名义上的交接，和几次和声细语的密切指导。但真正独立展开工作时，许多小功能增删改，我都要折腾个好几天才能厘清代码调用关系、算法原理，然后找到修改点谨慎细微龟速前行。进度追踪的人有的时候也催毛了，直接请专家大师出手，咔咔咔，不到半天就搞定了。当然，前期我当然尽量的”不耻上问”，但人吗，总是有遇到被激发“骨气”的时候。
这几天，好不容易搞好一个全新的功能模块，把代码推送给他合并编译。不曾想，出现了让我泣血的一幕。
我眼睁睁地、眼睁睁看着她把我辛苦敲入的代码注释/**/通通换成//，一份精美的代码，顿时成渣。
我询问缘由，她的回答是: 当代码里面充满注释符号/**/时，她想要用/**/注释整段代码时，就会很麻烦。 我理解了，因为/**/不支持嵌套。比如下面这样的语句是编译不过的。
我的手抬了抬，终究作罢。虽然我感觉到尊严被践踏，心爱的作品被蹂躏，但我还是开始反思。
许多软件规范、专家、有经验的工程，都建议或要求注释代码最好使用 /**/，他们的理由大略如下:
1. “//” 的注释的严密性不够。 例如
此时，a = b+c在一些编译器不会被执行。
因为"??/"会被编译器当作 \，变成C语言的换行符。于是这段代码等同于
就会被注释掉。大家有兴趣的，不妨去搜索一下"C语言 三字母词"
当然，哪怕没有??/， 自己打盹碰到delete键也是会屏蔽掉a=b+c的
2. “//” 的注释，是C++发展后才引进的。 有些早期的C编译器对这种注释是不支持的。代码要做到全平台兼容，这点是必需要考虑的。
因此，老外定义的C语言软件规范，无论是MISRA还是CMMI，一般都要求所有代码注释必须使用/**/。
君不见，那uCOS的最新版本源码，所有注释都是/**/。
君不见，那STM32的最新固件库，洋洋洒洒几十个文件，通篇皆没有用到//。
正是基于这样的理由，让我的心中充满了愠怒。但我仍然没有当场反驳她，因为这些理由还有些苍白无力。
1. 当时，那个什么三字母词“??x”到底是什么我已经忘了，没法立刻做试验编译给她看。
而且时候我里面作了编译实验，得到的是
"filename.c", line xxxx: Warning: #2532-D: support for trigraphs is disabled xx代码语句xx // ??/
trigraph金山词霸---> [traigra:f]三字母词
看吧，编译器都警告了，默认是不支持的。
2. 而且，所谓的//是C++的，早期的c编译器不支持。
这点谁鸟啊，我们只要现在，只用最新版本的编译器。
所以，我还要继续思考。
我要维护这个传统，为自己代言......
用户1264520 2014-1-22 14:11
用户1406868 2014-1-9 14:23
不错，深有同感
用户590697 2014-1-5 12:11
用户1625273 2014-1-3 11:04
用户439555 2014-1-2 15:29
用户1322475 2013-12-31 17:05
用户1685993 2013-12-27 21:51
用户1406868 2013-12-26 16:03
用户1639872 2013-12-25 00:10
用户1639872 2013-12-25 00:08