科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网软件频道肖桦:架构师任务--制定代码规范

肖桦:架构师任务--制定代码规范

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

制定项目的代码规范也是架构师的杂事之一,下面记一些制定规范的规范,Standar of Coding Standars。

2007年4月18日

关键字: 肖桦专栏 软件工程

  • 评论
  • 分享微博
  • 分享邮件
这个系列希望写一些正儿八经的架构设计之外的,属于架构师职责的杂七杂八的事情。

 制定项目的代码规范也是架构师的杂事之一,下面记一些制定规范的规范,Standar of Coding Standars。

1.规范的内容

  a.Standars在老外口中可以细化为Conventions、Rules、Guidelines和Best Practices,身为一份有价值的规范,除了定义最简单的格式、命名规则外,更要包含足够份量的禁条、指南和最佳实践。

  b.规范必须是经实践的广泛共识的标准,不是完美主义者凭空发明,认为这样子会更好的条款。

  c.条款必须有被描述的价值,没人会做的蠢事就不用再列了(比如编译器已经强制检查的,或者滥用goto语句这样的条款)

  d.条款可以分成必须遵循(I)、推荐遵循(II)与可选建议(III)几个等级。

  e.团员意见一致的规范比完美的规范更重要。

2.第0条规范---不要拘泥于细节,个人喜好与过时的东西不应该被标准化

    ----来自《C++ Coding Standards中文版》,很重要的条款。

    有些东西只是个人喜好与信仰问题(MS vs Unix),并不影响程序的正确性可读性,比如,花括号的位置,缩进,空格与缩进符,行的长度,只需要规定在一个文件、一个模块中必须一致就可以了。

    具体使用哪种风格其实并不影响可读性,不值得花太多的时间来争论,规范中更有价值的是格式以外的部分,比如How处理异常,How写log等。何况现代IDE一下就能转换格式。但若是阅读同一段代码时要在几种风格中切换就有点难受。

    过多过细的命名规定也不值得,而匈牙利记法,单入口单出口条例在书中被认为过时。

3.以别人的规范作基础

      a. C++

      b. Java

      c. Other

  •  Google Directory  和 Open Directory 上,每种语言都可能收集有Coding Standard/Styles。
  • RUP的文档中也有C++与Java Programing Guidline Examples。

4. Code Review
    善用自动review的工具如EclipseInellij IDEA的代码校验功能和CheckstylePMD 这些静态代码分析工具。

5.参考资料:
《The Art of Agile Development》Coding Standards一章

 

查看原文:http://blog.csdn.net/calvinxiu/archive/2007/04/17/1567553.aspx

    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章