本文章是由機器翻譯。
ALM Ranger
透過 StyleCop 實作靜態程式碼分析
你如何經常遇到令人費解的代碼?通常,它是不一致的格式、 無效注釋和缺乏使代碼不可讀的命名約定。作為小小的異常,常常忽略這種不一致,但他們可以作出很大的不同,在整體的可維護性的代碼。
瞥是一個偉大的工具,以保持在原始程式碼中的樣式和格式的一致性。像Visual Studio代碼分析,瞥執行靜態代碼分析。然而,與Visual Studio代碼分析,不同的是它通過掃描原始程式碼檔,而不是託管的代碼。此外,瞥只驗證的風格不一致和不執行的代碼優化和性能檢查。
在本文中,我會介紹瞥、 給你看它是如何工作和討論時通過它在您的專案中,應考慮哪些因素。最後,我會演示如何在您的Visual StudioTeam Foundation伺服器 (TFS) 生成中包括瞥執行。
瞥要點
瞥 (stylecop.codeplex.com) 是一個開放源碼的工具,在 C# 原始程式碼檔上執行靜態代碼分析。它與Visual Studio集成在一起,並顯示在內容功能表中,為您提供掃描當前檔或任何選定的檔或專案的選項。圖 1 Visual Studio專案的內容功能表上顯示可用的瞥選項。
圖 1 瞥內容功能表選項
當你選擇運行瞥或運行瞥 (全部重新掃描) 選項時,瞥分析所有的 C# 檔,並驗證它們為指定的瞥規則。如有違反,在錯誤清單視窗中會出現一個警告。
瞥設置檔這是瞥放其所有的配置選項的地方。此檔包含的資訊如選定的規則 ; 詞彙資訊 (如自訂單詞或首字母縮寫詞 ; 以及是否合併與設置檔中,父目錄的設置檔,如果有的話。
既然瞥遞迴查找的原始程式碼檔的父目錄中的設置檔,它是一種最佳做法保持的 Settings.StyleCop 檔的單個版本。維護一個檔並將其存儲在團隊專案的根可確保跨整個團隊專案使用相同的一組規則。
自訂字典檔除了允許將詞和首字母縮寫詞添加到自訂設置檔,瞥也能工作一個 CustomDictionary.xml 檔,作為Visual Studio代碼分析字典使用相同的格式。這允許您使用兩個相同的詞典檔。圖 2顯示字典檔的格式。
圖 2 自訂字典檔
<Dictionary>
<Words>
<Unrecognized>
<Word/>
</Unrecognized>
<Recognized>
<Word/>
</Recognized>
<Deprecated>
<Term PreferredAlternate=""/>
</Deprecated>
<Compound>
<Term CompoundAlternate=""/>
</Compound>
<DiscreteExceptions>
<Term />
</DiscreteExceptions>
</Words>
<Acronyms>
<CastingException>
<Acronym />
</CastingException>
</Acronyms>
</Dictionary>
解釋了瞥的基本知識的目的,我現在去通過涉及哪些是使您的開發團隊工作實踐的一個組成部分。
瞥規則這是瞥執行代碼的檔的檢查。有可用的一些規則外框,和,您可以編寫自己的自訂的規則如果你願意的話。瞥 wiki 詳細介紹如何編寫您自己的瞥規則 (見 bit.ly/12P665L)。
使用瞥的第一步決定哪些瞥規則使用。我強烈建議使用瞥的所有規則。然而,開發團隊經常有他們自己的編碼標準,並可能有關于某些瞥規則通過強推回。你必須平衡的長期利益一貫風格,反對的小的不便,它可能會導致可維護的代碼。像很多好的做法,一旦你養成的使用瞥,它將成為第二天性。在任何情況下,您的團隊將使用一刀切的瞥規則達成至關重要。
瞥規則落在以下七個類別:
- 文檔的規則:驗證文檔中的元素的原始程式碼檔的適宜性。
- 佈局規則:驗證佈局,並在原始程式碼檔中的行間距。
- 可維護性規則:驗證原始檔案中的可維護性方面如不需要的括弧或單個檔中的多個類的存在。
- 命名規則:驗證方法和變數的名稱替代的性。
- 排序規則:驗證代碼的內容正確排序。
- 可讀性的規則:驗證的代碼是正確地格式化和可讀。
- 間距規則:驗證間距在代碼中的內容是有效和適當。
你可以閱讀更多有關瞥類別和它們各自的規則瞥規則檔在 bit.ly/191GgiQ。
將瞥添加到您的團隊專案生成
這是很好有瞥規則選擇並存儲在設置檔中,但確保瞥一貫執行的所有原始程式碼的唯一方法是作為生成過程的一部分來運行它。
做法有兩種:
- 所以,它執行編譯專案時,將與 C# 專案的MSBuild檔集成瞥。瞥文檔 (bit.ly/13ZX2xL) 描述如何這樣做。
- 添加瞥到團隊生成您持續集成,以便它執行的每次簽入。
我將解釋如何在團隊生成您持續集成運行瞥。如果您使用的封閉的生成,執行瞥將確保與侵犯任何代碼檔是不簽入。如果不使用在封閉生成,生成中斷仍會提示您要修復侵犯行為,當您簽入的代碼。
在團隊建設中運行瞥,過程必須從生成工作流中的一個活動中被調用。我會用瞥活動從稱為社區 TFS 生成擴展的開放源碼專案 (tfsbuildextensions.codeplex.com)。社區 TFS 生成擴展是一套包含一系列可重用工作流活動,您可以簡單地拖放到您的團隊生成過程範本庫。
組建控制器更改你需要自訂的團隊生成設置自訂之前要做的第一件事您組建控制器的程式集路徑。這是從哪裡的生成代理負載為他們在生成工作流中找到的任何自訂活動的程式集的位置。
若要添加自訂程式集,在一個適當的位置,在您的團隊專案創建一個新的資料夾。我命名的新資料夾自訂程式集,只是下面的團隊專案根資料夾 BuildProcessTemplate 下面創建它。現在,請檢查在下列程式集:
- StyleCop.dll
- StyleCop.CSharp.dll
- StyleCop.CSharp.Rules.dll
- TFSBuildExtensions.Activities.dll
- TFSBuildExtensions.Activities.StyleCop.dll
下一步是配置您要使用這些程式集的組建控制器。做法如下:
- Team 總管中生成連結,按一下。按一下操作,然後選擇管理組建控制器。
- 從出現的對話方塊中,選擇您的組建控制器並按一下屬性按鈕。
- 將組建控制器屬性對話方塊,在"自訂程式集版本控制路徑"屬性設置為自訂程式集創建的資料夾,較早前在團隊專案中,如中所示圖 3。
圖 3 組建控制器屬性
按一下確定,關閉屬性對話方塊。此時,組建控制器配置為載入您的自訂活動。下一步是以自訂您的生成範本。
瞥注意事項
在這裡是要注意的一些注意事項:
- 與Visual Studio代碼分析,不同瞥不支援Visual Basic.NET 和僅可用於用 C# 編寫的原始程式碼檔。
- 在寫這篇文章的時候,瞥沒可用的Visual Studio2013年。
- 承載組建控制器是由Visual StudioTeam Foundation服務承載于雲中組建控制器。如果你使用的處所上生成伺服器配置此組建控制器的步驟是相同的。
- 這篇文章用Team Foundation伺服器 (TFS) 2012年。步驟是相同的 TFS 2010 和 TFS 2013 年。請確保您正在使用正確版本的 TFS 生成擴展。
自訂生成範本
對於每一個新的團隊專案,TFS 將創建生成範本外框的數目。這些範本在一個名為 ProcessBuildTemplates,它位於團隊專案的根資料夾中創建的生成。通過採取 DefaultTemplate.11.1.xaml 範本的副本,並自訂要添加瞥活動啟動。我創建了 DefaultTemplate.11.1.xaml 檔的副本,並改名為 CustomTemplate.xaml。
要自訂生成工作流,您會需要您的開發環境中添加自訂活動。要這樣做,在Visual Studio中創建一個新的工作流活動專案。在添加新專案對話方塊中,確保選擇 Microsoft.NET 框架 4.5 作為目標平臺。下一步是將連結添加到檔 CustomTemplate.xaml 在新創建的專案中。要做到這一點,按右鍵該專案,選擇添加現有項、 流覽到的檔 CustomTemplate.xml 和按一下添加連結按鈕作為。
設置您的開發環境的最後一步是在允許拖放的工具箱視窗中添加瞥活動。要這樣做,在您的工具箱視窗中按右鍵"活動"下面的區域,並選擇添加選項卡選項。名稱的新選項卡"TFS 構建擴展"。用滑鼠右鍵按一下該選項卡名稱,然後選擇"選擇項"。流覽到 TfsBuildExtensions.Activities.Stylecop.dll 程式集並按一下確定。現在可以打開 CustomTemplate.xaml 檔,並拖動到它瞥活動。
生成範本自訂你應該早在生成過程中運行瞥。這將允許生成快速失敗如果遇到任何衝突。因為瞥需要原始程式碼檔進行掃描,瞥可以執行所在的第一個地方是後的初始化工作區序列內的代理上運行序列,如中所示圖 4。
圖 4 瞥活動的放置位置
確定生成工作流以添加瞥活動中適當的位置下, 一步是添加一個序列活動。運行瞥到重命名序列活動。最後上市的我運行瞥序列所示圖 5。
圖 5 運行的瞥序列
代碼示例圖 6 詳細介紹了在運行瞥序列、 它們的類型和它們的各自用途定義的變數。
圖 6 在運行的瞥序列中定義的變數
變數名稱 | 類型 | 描述 |
SourceCodeFiles | IEnumerable < 字串 > | 存儲的所有檔將由瞥掃描的名稱。 |
IsSuccess | 布林值 | 存儲是否瞥活動發現任何違法行為。 |
ViolationCount | Int32 | 存儲的瞥侵犯的計數。 |
工作流也包含稱為 StyleCopSettingsFile 存儲瞥設置檔的路徑的字串類型的參數。
在運行瞥序列中的第一個活動是 FindMatchingFiles 的活動。該活動載于 Microsoft.TeamFoundation.Build.Workflow.dll 程式集並返回給定的檔案模式匹配的所有檔的清單。圖 7 描述了這一活動的屬性的設置方式。
圖 7 FindMatchingFiles 活動屬性
屬性名稱 | 值 |
DisplayName | FindMatchingFiles |
IsSuccess | String.Format ("{0} \**\*.cs",BuildDirectory) |
結果 | SourceCodeFiles |
該活動通過尋找所有 C# 的模式 (*.cs) 中所生成的目錄,和它的檔 SourceCodeFiles 枚舉中返回的結果。
在序列中的下一個活動是 ConvertWorkspaceItem 活動,在其中駐留在大會 Microsoft.TeamFounda揚天。Build.Workflow.Activities.dll。該活動將轉換為給定的瞥設置檔的伺服器路徑 — — 作為一個參數傳遞 — — 在生成伺服器上的本地路徑。這項活動的屬性顯示在圖 8。
圖 8 獲取本地設置檔案屬性
屬性名稱 | 值 |
Direction | ServerToLocal |
DisplayName | 獲取本地設置檔 |
輸入 | StyleCopSettingsFile |
結果 | StyleCopSettingsFileLocalPath |
工作區 | 工作區 |
現在,檢索原始程式碼檔的名稱並建立了瞥設置的位置,運行瞥序列中的下一個活動是瞥活動。圖 9 顯示如何設置瞥活動的屬性。
圖 9 執行瞥屬性
屬性名稱 | 值 |
DisplayName | 執行瞥 |
LogExceptionStack | True |
SettingsFile | StyleCopSettingsFile |
ShowOutput | True |
SourceFiles | SourceCodeFiles.ToArray() |
結果 | StyleCopSettingsFileLocalPath |
成功 | IsSuccess |
TreatWarningsAsErrors | True |
該活動需要枚舉 SourceCodeFiles — — 轉換為數組 — — 作為輸入,並返回結果和違反中的 IsSuccess 和 ViolationCount 的變數,分別計數。它具有給定顯示名稱的 Execute 瞥,並設置將警告視為錯誤,並會生成失敗,如果遇到任何錯誤。
在運行瞥序列中的最後一個活動是寫生成消息的活動。該活動設置為顯示結果和侵犯計數。圖 10 顯示如何設置屬性的這項活動。
圖 10 寫生成消息活動屬性
屬性名稱 | 值 |
DisplayName | 完成消息 |
重要性 | Microsoft.TeamFoundation.Build.Client.BuildMessageImportance.Normal |
訊息 | String.Format ("瞥了 {0} 侵犯與已完成",StyleCopViolationsCount) |
現在準備好使用您的自訂生成範本。保存並簽入該檔 CustomTemplate.xaml。若要使用新的生成範本,打開您的組建定義按一下進程展開生成過程範本、 按一下新建按鈕。在顯示的新的過程範本對話方塊中,選擇"選擇一個現有的 XAML 檔"選項並流覽到的 CustomTemplate.xaml 檔。
將 StyleCopSettingsFile 參數的值設置為 Settings.StyleCop 檔的位置。按一下保存,保存組建定義。現在準備好使用您的生成與瞥。對封閉生成使用此生成範本,最好。這將確保簽入的原始檔案都沒有任何瞥侵犯行為。
下一個步驟
我已經演示了如何使用瞥在您的團隊建設中加強靜態代碼分析。靜態代碼分析促進更好的編碼標準,並可確保所有簽入的代碼符合你的標準你團隊生成在運行。同樣,您可以在您的團隊建設實施其他最佳做法。MicrosoftALM Rangers產生了大量的有用生成範本,您可以使用在Team Foundation構建自訂指南 (vsarbuildguide.codeplex.com) 專案。此外,您可以編寫您自己的活動或使用社區 TFS 生成擴展專案中可用的活動選擇。
Hamid Shahid· 是 Microsoft ALM 護林員和一名獨立顧問具有 12 年以上的經驗設計和開發企業軟體。他有濃厚的興趣,促進在 Microsoft ALM 技術的最佳做法。他可以通過他的博客在到達 hamidshahid.blogspot.com 和後面可以在 Twitter 上 twitter.com/hamid_shahid。
由於以下ALM Rangers和技術專家對本文的審閱:邁克 Fourie (獨立顧問),Willy-Peter Schaub(Microsoft) 和派特裡夏 · 瓦格納 (Microsoft)
邁克 Fourie 是具有 13 年以上軟體發展經驗的獨立顧問公司專攻生成和部署自動化。他是一個 Microsoft ALM 最有價值球員和尊敬的 ALM 護林員。他可以通過他的博客在到達 freetodev.com。您也可以按照他在 Twitter 上 twitter.com/mikefourie。
Willy-Peter Schaub是與Visual StudioALM Rangers在微軟加拿大發展中心的高級專案經理。年年-八十年代以來,他一直在努力的簡單性和可維護性軟體工程中。讀他的博客在 blogs.msdn.com/b/willy-peter_schaub 和跟隨他在 Twitter 上 twitter.com/wpschaub。