标签: 软件规范
相关博文
-
3.空格、换行、常量替换、{}保护、还有效率。 if((long_state_var==1)||(long_state_var==2)||((ch0x2F)(ch0x3A))) do_something(); 看到这种代码，他就感觉 浑身难受、头晕恶心 ….. 狂吼一声，这段代码立马会给改成这样。 if ((long_state_var==1)||(long_state_var==2) \ ||((ch0x2F)(ch0x3A))) { do_something(); } 长字符行要换行，模块要添加{} 保护，这是做人的底线。 再瞄一眼，会发现没有空格也很让人难过。 赶紧快速编辑了而下，舒了口气。 if ( (long_state_var == 1) \ || (long_state_var == 2) \ || ((ch0x2F) (ch0x3A)) ) { do_something(); } 加上空格的美化，更有层次感。 当他开始维护这段代码，搞清楚逻辑后， 无意义的常量就会被处理成这样的， 长变量名也会被适当缩短。 而0x2F、0x3A这种坑爹的的常量， 则会被他心里狠狠地鄙视: “丫丫的，原创者这是在炫智商、秀优越吗？”。 #define MODE_NAME_1 (1) /* 简单描述模式 1 */ #define MODE_NAME_2 (2) /* 简单描述模式 2 */ if ( (stat == MODE_NAME_1) \ || (stat == MODE_NAME_2)) \ || ((ch='0') (ch='9')) ) /* 数字字符 */ { do_something(ch); } 常量用宏替代，这样的代码意图会比较清晰。 后来他感觉，还是有些不妥。干脆又改了下，最后变成这样。 #include …… if ( (stat == MODE_NAME_1) \ || (stat == MODE_NAME_2)) \ || (is_digit(ch)) ) { do_something(ch); } is_digit 的加入，使得代码与注释浑然天成。 后来他在优化过程中发现，ch的值在99%的情况下都满足'0'~'9'， 这个时候，这段代码又会被优化成这样的。 if (is_digit(ch)) { do_something(ch); } else if ((stat == MODE_NAME_1) \ || (stat == MODE_NAME_2)) { do_something(ch); } else { /* 已考虑无误 */ } 为了效率，可以牺牲一点代码可阅读性。
-
观文识人，代码无疑是了解一个程序员的最佳途径。 且不论算法思路，单就代码的界面风格，便可知一二。 1. 追求精美的对齐。 尽可能精确到每一个"断点"，是他的追求。 2.没有tab字符，而是采用4个或8个空格键代替。 编辑时敲入的是tab键，但其编辑器会设置"文件保存时tab用空格字符替代" 为何呢，因为这样的代码，无论在那种编辑器上打开，都一定是对齐的。 拷给别人，才不担心形象受损。 下接： 一线研发之声 之 完美主义者的程序员特征 二
-
上接： 一线研发之声 之 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”是一个如此的醒目，很容易成为一个评估软件质量、工作绩效的搜索关键词。 从管理的角度，这个是可以量化的。因此， 理由三: 使用/**/注释代码，有利于公司进行软件质量控管，对程序员绩效考核。 这三个理由，足够为自己代言吗？
