瑣記之C#程式設計風格

     一般原則

1、保持原有風格

        修改别人編寫的軟體時，應遵循原始代碼的風格。修改時不要引入新風格，也不要僅為了吻合新風格而重寫舊軟體。在一個源代碼檔案中存在多種風格會使代碼更難讀懂。為修改風格而重寫代碼将産生本可避免的缺陷，增加軟體成本。（寫機器懂的代碼容易，寫人懂的代碼難。）

2、堅持最小驚奇原則

       最小驚奇原則建議你避免做出可能讓其他軟體開發人員吃驚的事情。這意味着，軟體所展示的互動及行為方式必須可預料并保持一緻。如果不是這樣，文檔就必須清晰地指出所有非通常的用法或行為。

       為了降低他人在使用你的軟體時遭遇驚奇的可能性，你應當在軟體的設計、實作、打包和文檔中強調以下原則：

       簡單性：用簡單的類和簡單的方法滿足使用者期望。

清晰性：確定每個類、接口、方法、變量和對象都有清晰的目的。闡明何時、何處、如何使用它們。

完整性：提供任一可能的使用者期望找到和使用的最小功能。建立完整文檔，描述所有特性和功能。

一緻性：相似褓的外觀和行為應該相同，不同褓的外觀和行為應該不同。應該盡可能制定并遵守相關标準。

健壯性：對軟體中可能出現的錯誤和異常做出預測，并将解決方法記入文檔。不要隐藏錯誤，也不要等使用者去發現錯誤。

3、第一次就做對

        對所有的代碼實施這條規則，不僅限于正式産品的代碼。原型或試驗性代碼多半會用到最終産品中，是以你該洞悉先機。即便代碼永遠不會采用到正式産品中，别人也有可能讀到它。任何閱讀你的代碼的人，都會從你的專業性和貫徹這些規則的先見之明中獲益匪淺。

4、記錄所有非規範行為

沒有十全十美、普适一切的标準。有時你會有偏離某條既定标準的需要。無論如何也要努力保持清晰和一緻。

在決定忽略某條規則之前，你應該先确信自己了解該條規則存在之理由，以及不采用該規則會引起的後果。如果你決定要違反某條規則，記錄下這麼做的原因。這是第一守則。

5、考慮采用代碼檢查工具強制遵循編碼标準

可采用源代碼分析工具檢查代碼是否符合編碼标準和最佳實踐。例如，FxCop是一種流行的.NET代碼分析工具，它利用反射技術、MSIL解析和調用圖分析來檢查代碼是否符合.NET架構設計的指導原則。FxCop可擴充，是以能加入你所在組織的特殊編碼标準。