【朱永光】Microsoft Source Analysis for C#的推波助瀾作用

          強制編碼風格是一個長期被熱烈爭論的話題。人們不僅為團隊應該遵循何種編碼風格而爭論不休，同時還要爭論究竟是否應該確立一個標準的編碼風格。現在，微軟釋出了StyleCop，這是他們在內部使用的一個編碼風格強制工具，微軟的這一舉措無疑將起到推波助瀾的作用。 
         StyleCop，也即所謂的微軟C#原始碼分析器（Microsoft Source Analysis for C#），用途和FxCop相似，只不過作用物件是原始碼。此外，它和FxCop一樣是源於微軟的內部工具，在發展到一定程度之後，微軟覺得對其他人也有 用，於是被公開發布。不過，StyleCop的自定義程度不如FxCop那麼高。 
         

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的方式編寫我的程式碼，但它總是警告我，我的每行程式碼都有tab在其中。
  同時，Daniel Stolt也問到了關於VB的情況：為.NET開發人員提供一些額外工具總是受歡迎的——但為什麼只有C#的？程式碼格式的強制規則對於VB開發人員來說也是非常需要的。
  顯然，VB程式碼編輯器在對關鍵字和操作符進行縮排和空格的處理中，已經具有自動格式化的一些初步支援，但還不夠接近StyleCop所支援的效果。
  順便說來，我完全同意Nick Berardi對於tabs vs spaces的觀點：使用tabs有什麼問題？難道按4-5次方向按鈕比直接指向某個位置更有某種優勢？還是在原始碼檔案中儲存4-5個空白字元存在著某種好處？
  

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/12639172/viewspace-364684/，如需轉載，請註明出處，否則將追究法律責任。