歡迎光臨
每天分享高質量文章

用StyleCop規範團隊代碼

前言

編碼風格,每個人都是有不同的特點,風格各異,而且一個人在不同的時期,編碼風格的差異也可能是非常大的,好比學生時代,剛工作的時候,工作一段時間後等。

在一個團隊中,或一個專案中,如果出現了N種風格,這個可能就是比較頭疼了,尤其是風格差異很大的時候。

一個專案一種風格或許還可以接受,如果一個專案風格都不一樣,那就有點難受了,就更不用說整個團隊的了。長久來看,團隊之間,難免會有人員的調動,所以統一整個團隊的編碼風格還是很有必要的。

統一了編碼風格會帶來什麼好處呢?下麵列出幾點

  1. 便於代碼審查
  2. 新人(新同事/跨專案組同事)接手不會覺得雜亂無章

下麵來先看看本文的重點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


 

    閱讀原文

    赞(0)

    分享創造快樂