• 2009-11-29

    更新编码规范

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://www.blogbus.com/dreamhead-logs/52561945.html

    职业程序员都知道编码规范这个东西,目的是为了统一公司的编码风格,让代码好维护。通常的编码规范大抵是诸如,常量名要大写、大括号应该跟在当前行之后,或是另起一行之类的。

    其实,编码规范是要与时俱进的,所以,我们看到,有些好的编码规范还会把一些经常出问题的地方放到编码规范里面,比如C语言里面,条件的地方应该把变量写在后面,像if (NULL == p) { ... }。更有甚者,会把诸如Effective XXX之类书中的内容,也加入到编码规范之中。

    原本,编码规范的目的是为了让大家未来的日子过得好一点。但是,如果遵循这些编码规范,代码依然是难以理解,也许,编码规范到了又该更新的时候了。

    一个实践是把函数代码行数的限制写入编码规范。我的几个同事在一个20人左右的团队进行了这种尝试,他们设定的标准是40行,这是考虑了团队的现状指定的标准。

    这个团队是由一些经验很少的程序员组成,遵循原有的编码规范,他们总能把代码写成维护之前就难以理解了。团队原来有个度量标准,就是圈复杂度,而原来的圈复杂度要求是15以下,开发到一定程度之后,就要想办法专门来降圈复杂度。

    我的同事们不仅仅是设定了新的编码规范,更把它做到提交规则里面,也就是说,如果有函数的代码行超出一定规模,就会提交失败。在我几个同事引导之下,结果是,大多数代码实际上可以比这个标准低得多,团队的代码逐渐清晰起来,至少代码是可以理解的,那个曾经让人很担忧的圈复杂度降到了平均只有1.X,没人会再为这个指标担忧了。现在我们正准备在一个更大的团队内采用这种新的编码规范。

    代码之所以难于理解主要是坏味道,而长函数是名列榜首的坏味道。在一个大团队,指望每个人去理解小函数的价值不是那么容易。对于团队而言,编码规范如同法律,不得触犯。把函数写小做到编码规范里面,迫使人那些编码习惯不好的程序员向好的方向迈进。编码规范无非是好习惯的集合,只不过很多团队尚未认识到小函数是好习惯。当然,仅仅写小代码是不够的,但这是非常重要的第一步。

    类似的改进代码规范还可以有一些,比如《ThoughtWorks文集》第六章《对象健身操》里面的内容,有些是可以写入编码规范中的。

    如果代码遵循了编码规范依然难懂,不妨更新一下编码规范!

    分享到:

    历史上的今天:

    引用地址:

    评论

  • 太赞同你的观点了,我觉得提高代码质量可以先从写短函数做起。
  • 感谢分享~
    我们公司文化里有句口号:A little change can make big difference.
    我想这句话用在这里也比较贴切。