StyleCop- 微軟源代碼強制工具 Microsoft’s Style Enforcement Tool for C#

強制編碼風格是一個長期被熱烈爭論的話題。人們不僅為團隊應該遵循何種編碼風格而爭論不休，同時還要爭論究竟是否應該確立一個標準的編碼風格。現在，微軟發布了StyleCop，這是他們在內部使用的一個編碼風格強制工具，微軟的這一舉措無疑將起到推波助瀾的作用。

StyleCop，也即所謂的微軟C#原始碼分析器（Microsoft Source Analysis for C#），用途和FxCop相似，只不過作用對象是原始碼。此外，它和FxCop一樣是源於微軟的內部工具，在發展到一定程度之後，微軟覺得對其他人也有 用，於是被公開發布。不過，StyleCop的自訂程度不如FxCop那麼高。

Source Analysis的最終目標是允許你產生優雅、一致的代碼，讓你的團隊成員和其他查看你代碼的人容易閱讀。為達到這一目的，Source Analysis不允許它的規則被過多的配置。Source Analysis使用一種統一的方式來處理代碼風格、布局和可讀性規則。你很可能並不認同所有的規則，甚至會發現某些規則並非如你所願。然而，在微軟內部 使用這個工具的大部分團隊在經過短暫的調整期後，都能夠欣然接受Source Analysis強制要求的這些規則，甚至開始認為如果不使用這種風格來編寫代碼，就很難閱讀。

Jason Allor聲稱由這個工具所強制要求的大約200條規則與Visual Studio的預設設定是相容的。遺憾的是，他忘記提到Visual Studio具有6個完全不同的預設設定集合，其中多數與這個工具互相矛盾的。

這個工具涉及的方麵包括：

• 支援檔案內容
• 調試文本
• 編排元素頭和檔案頭中的文檔格式
• 元素、語句、運算式和查詢子句的布局
• 行空格
• 元素、欄位和變數的命名
• 大括弧、圓括弧、方括弧等的位置
• 在方法聲明或方法調用中方法參數的位置
• 關鍵字和操作符周圍的空格
• 在類中元素的標準順序
• 存取修飾詞的使用
• 內建類型的使用

在空白的控制台應用程式上運行這些規則，會返回9個錯誤，如果你開啟“Keep Tabs”設定，則會出現16個錯誤。一些規則稍顯笨拙，例如要求“using”指示符必須放在命名空間內，而不是放在檔案頂部。

已經有人在抱怨這個工具缺乏校正的支援。Dustin Norman寫道：

在將這個工具運行在一個較小的程式集上時，這個工具要我手動修改561個違規錯誤，而它卻不能在不影響代碼語義的基礎上自動為我修複錯誤——這真的要讓我崩潰了！

古老的tabs vs spaces爭論【譯者註：即代碼的縮排是用Tabs來實現還是用Spaces來實現】又被提及，而且我們還不能禁用這一規則。Nick Berardi寫道：

真是開玩笑。Tabs居然不被允許。相反，只能使用空格。這個主意糟透了，因為它會破壞語句塊的布局，例如一個變數使用3個空格，而其他變數則使用了4個。無論如何，應該允許禁用類似tab規則這樣毫無意義的規則。

如 果能夠禁用這些規則，這個工具就更好了。我知道你會說他們已經夠好了。但是我完全不同意使用空格來代替tab。這是毫無邏輯可言的，或許只有在Vi編輯器 第一次出現從而引發了開發人員之間的“聖戰”可堪比擬吧。我喜歡用Tab的方式編寫My Code，但它總是警告我，我的每行代碼都有tab在其中。

同時，Daniel Stolt也問到了關於VB的情況：

為.NET開發人員提供一些額外工具總是受歡迎的——但為什麼只有C#的？代碼格式的強制規則對於VB開發人員來說也是非常需要的。

顯然，VB代碼編輯器在對關鍵字和操作符進行縮排和空格的處理中，已經具有自動格式化的一些初步支援，但還不夠接近StyleCop所支援的效果。

順便說來，我完全同意Nick Berardi對於tabs vs spaces的觀點：使用tabs有什麼問題？難道按4-5次方向按鈕比直接指向某個位置更有某種優勢？還是在原始碼檔案中儲存4-5個空白字元存在著某種好處？

在支援自動校正方面確實存在一些問題，目前還沒有給出解決這個問題的時間表呢。