作者：
江南白衣，原文地址：
http://blog.csdn.net/calvinxiu/archive/2007/04/17/1567553.aspx，转载请保留。
这个系列希望写一些正儿八经的架构设计之外的，属于架构师职责的杂七杂八的事情。
制定项目的代码规范也是架构师的杂事之一，下面记一些制定规范的规范，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
4. Code Review
善用自动review的工具如Eclipse与 Inellij IDEA的代码校验功能和Checkstyle、PMD 这些静态代码分析工具。
5.参考资料：
《The Art of Agile Development》Coding Standards一章
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1567553