作者：
江南白衣，原文地址：
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