首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

一线研发之声 之 C代码注释引发的“血案” <二>

一线研发之声 之 C代码注释引发的“血案” <二>

我开始思考,还有什么强劲有力的理由,来支持我恪守的真理: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”是一个如此的醒目,很容易成为一个评估软件质量、工作绩效的搜索关键词。从管理的角度,这个是可以量化的。因此,
理由三: 使用/**/注释代码,有利于公司进行软件质量控管,对程序员绩效考核。


这三个理由,足够为自己代言吗?
返回列表