知識星球前言
編碼風格，每個人都是有不同的特點，風格各異，而且一個人在不同的時期，編碼風格的差異也可能是非常大的，好比學生時代，剛工作的時候，工作一段時間後等。
在一個團隊中，或一個專案中，如果出現了N種風格，這個可能就是比較頭疼了，尤其是風格差異很大的時候。
一個專案一種風格或許還可以接受，如果一個專案風格都不一樣，那就有點難受了，就更不用說整個團隊的了。長久來看，團隊之間，難免會有人員的調動，所以統一整個團隊的編碼風格還是很有必要的。
統一了編碼風格會帶來什麼好處呢？下麵列出幾點
- 便於程式碼審查
- 新人(新同事/跨專案組同事)接手不會覺得雜亂無章
- …
下麵來先看看本文的重點StyleCop。
什麼是StyleCop？
這裡取用維基百科的介紹
StyleCop is an open-source static code analysis tool from Microsoft that checks C# code for conformance to StyleCop’s recommended coding styles and a subset of Microsoft’s .NET Framework Design Guidelines. StyleCop analyses the source code, allowing it to enforce a different set of rules from FxCop (which, instead of source code, checks .NET managed code assemblies). The rules are classified into the following categories:
- Documentation
- Layout
- Maintainability
- Naming
- Ordering
- Readability
- Spacing
簡單理解，開源的靜態程式碼分析工具，用來檢查程式碼是否符合推薦的編碼風格。
它的開源地址: https://github.com/StyleCop/StyleCop
其在README的最後，建議我們(使用Visual Studio 2015或更高版本的開發人員)使用的是StyleCopAnalyzers。
所以，後面我們用到的是它，StyleCop規則基於.NET編譯器(Roslyn)的實現。
下麵透過一個示例來介紹它的簡單使用。
示例
當我們新建一個.NET Core的控制檯程式之後，大致就是下麵的樣子。可以看到是沒有任何警告的。
透過Nuget安裝StyleCop.Analyzers，或直接在csproj裡面加下麵的內容。
<ItemGroup>
<PackageReference Include="StyleCop.Analyzers" Version="1.1.1-rc.94">
<PrivateAssets>AllPrivateAssets>PackageReference>ItemGroup>
在回到Program.cs，馬上就可以看到有波浪線了~~
這個時候我們需要狠一點，把專案的所有警告級別的提示都當成錯誤來看待。
<PropertyGroup>
<TreatWarningsAsErrors>trueTreatWarningsAsErrors>PropertyGroup>
加了這個之後，編譯就立馬出錯了。
在編譯不透過時，還是ERROR級別的錯，只能乖乖的去改了。
按照提示，一個個修改之後，還是有一個SA0001的錯誤提示。
要修複這個問題，需要參考這個檔案 SA0001.md
啟用一下生成XML檔案，同時加幾個禁止顯示的警告即可。
<PropertyGroup>
<TreatWarningsAsErrors>trueTreatWarningsAsErrors>
<GenerateDocumentationFile>trueGenerateDocumentationFile>
<NoWarn>$(NoWarn),1573,1591,1712NoWarn>PropertyGroup>
這個時候再build，就不會有錯誤了。
對於這麼簡單的一個空專案，都有不少要修改的地方，就可以知道，預設的規則是比較嚴格的。那麼我們有沒有辦法避免應用某些規則呢？答案是肯定的。
我們可以透過新增程式碼分析規則集來自定義。
有兩個方式新增，一個是直接新增新建項；一個是透過修改分析器裡面的規則集嚴重性，修改後會自動生成。
下麵我們透過修改兩個規則來體驗一下。
一個是不想要上面的頭部(SA1200)，一個是using可以在名稱空間外面(SA1633)。
下麵是示例程式碼。
xml version="1.0" encoding="utf-8"?><RuleSet Name="Demo Analyzer Rules" Description="Analyzer rules for Demo." ToolsVersion="15.0">
<Rules AnalyzerId="StyleCop.Analyzers" RuleNamespace="StyleCop.Analyzers">
<Rule Id="SA1200" Action="None" />
<Rule Id="SA1633" Action="None" />
Rules>RuleSet>同時，還要修改csproj檔案
<PropertyGroup>
<TreatWarningsAsErrors>trueTreatWarningsAsErrors>
<GenerateDocumentationFile>trueGenerateDocumentationFile>
<NoWarn>$(NoWarn),1573,1591,1712NoWarn>
<CodeAnalysisRuleSet>..\test.rulesetCodeAnalysisRuleSet>PropertyGroup>
去掉程式碼的頭部，和把using放到外面，再build一下專案，就可以正常透過了。
既然可以自己定義，那麼就必然有這樣一個問題，每個人可能都會想把自己的習慣放開，這樣的話，這個規則就是一個透明的存在了！！
換句話說，必須要有一些硬性規定，必須要有一些取捨。我們可以向某些開源專案借鑒，同時在他的基礎上做簡單的新增刪除，個人覺得應該可以適應大多數的情況了。
下麵放出幾個覺得不錯的參考。
- Autofac 目前我就是以這個為基礎的
- EntityFrameworkCore
在程式碼分析規則集的基礎上，還可以用Stylecop.json來微調某些規則的行為。
當把SA1633恢復之後，提示的第二個選項就是新增Stylecop.json配置檔案
新增之後，還要在csproj裡面做設定
<ItemGroup>
<AdditionalFiles Include="stylecop.json" />ItemGroup>關於Stylecop.json的具體配置，可以參考Configuring StyleCop Analyzers，這裡不繼續展開。
除了上面的辦法，還可以透過安裝擴充套件StyleCop來處理。
安裝後，右擊專案的時候就可以看到StyleCop相關的選單。
總結
在團隊內保持一樣的編碼風格，並能在開發過程中糾正相應的錯誤，這是編寫可維護和可讀程式碼的重要一步，同樣也是程式碼審查的重要一步！
當然，在團隊內推行這類規範，還是要多多聽取團隊成員的意見，也要定時檢查規則是否需要更新，畢竟時代在進步！只要達成一致，就是好規則，就應該要遵守。
StyleCop是一個很不錯的工具，用的好就是利器。可以把它和cli模板專案相結合，這樣建立的新專案就都“內嵌”了一樣的規則了。
友情提示，在老專案新增這個要慎重，不然會有一陣陣酸爽。
相關文章
- 程式碼審查工具StyleCop
- StyleCop: A Detailed Guide to Starting and Using It
- Automated, portable code style checking in .NET Core projects
原文地址：https://www.cnblogs.com/catcher1994/p/10375823.html
.NET社群新聞，深度好文，歡迎訪問公眾號文章彙總 http://www.csharpkit.com 
