用StyleCop规范团队代码
前言
編碼風(fēng)格,每個(gè)人都是有不同的特點(diǎn),風(fēng)格各異,而且一個(gè)人在不同的時(shí)期,編碼風(fēng)格的差異也可能是非常大的,好比學(xué)生時(shí)代,剛工作的時(shí)候,工作一段時(shí)間后等。
在一個(gè)團(tuán)隊(duì)中,或一個(gè)項(xiàng)目中,如果出現(xiàn)了N種風(fēng)格,這個(gè)可能就是比較頭疼了,尤其是風(fēng)格差異很大的時(shí)候。
一個(gè)項(xiàng)目一種風(fēng)格或許還可以接受,如果一個(gè)項(xiàng)目風(fēng)格都不一樣,那就有點(diǎn)難受了,就更不用說(shuō)整個(gè)團(tuán)隊(duì)的了。長(zhǎng)久來(lái)看,團(tuán)隊(duì)之間,難免會(huì)有人員的調(diào)動(dòng),所以統(tǒng)一整個(gè)團(tuán)隊(duì)的編碼風(fēng)格還是很有必要的。
統(tǒng)一了編碼風(fēng)格會(huì)帶來(lái)什么好處呢?下面列出幾點(diǎn)
便于代碼審查
新人(新同事/跨項(xiàng)目組同事)接手不會(huì)覺(jué)得雜亂無(wú)章
...
下面來(lái)先看看本文的重點(diǎ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
簡(jiǎn)單理解,開(kāi)源的靜態(tài)代碼分析工具,用來(lái)檢查代碼是否符合推薦的編碼風(fēng)格。
它的開(kāi)源地址:?https://github.com/StyleCop/StyleCop
其在README的最后,建議我們(使用Visual Studio 2015或更高版本的開(kāi)發(fā)人員)使用的是StyleCopAnalyzers。
所以,后面我們用到的是它,StyleCop規(guī)則基于.NET編譯器(Roslyn)的實(shí)現(xiàn)。
下面通過(guò)一個(gè)示例來(lái)介紹它的簡(jiǎn)單使用。
示例
當(dāng)我們新建一個(gè).NET Core的控制臺(tái)程序之后,大致就是下面的樣子。可以看到是沒(méi)有任何警告的。
通過(guò)Nuget安裝StyleCop.Analyzers,或直接在csproj里面加下面的內(nèi)容。
<ItemGroup><PackageReference Include="StyleCop.Analyzers" Version="1.1.1-rc.94"><PrivateAssets>All</PrivateAssets></PackageReference></ItemGroup>在回到Program.cs,馬上就可以看到有波浪線了~~
這個(gè)時(shí)候我們需要狠一點(diǎn),把項(xiàng)目的所有警告級(jí)別的提示都當(dāng)成錯(cuò)誤來(lái)看待。
<PropertyGroup><!-- other... --><TreatWarningsAsErrors>true</TreatWarningsAsErrors></PropertyGroup>加了這個(gè)之后,編譯就立馬出錯(cuò)了。
在編譯不通過(guò)時(shí),還是ERROR級(jí)別的錯(cuò),只能乖乖的去改了。
按照提示,一個(gè)個(gè)修改之后,還是有一個(gè)SA0001的錯(cuò)誤提示。
要修復(fù)這個(gè)問(wèn)題,需要參考這個(gè)文檔?SA0001.md
啟用一下生成XML文檔,同時(shí)加幾個(gè)禁止顯示的警告即可。
<PropertyGroup><!-- other... --><TreatWarningsAsErrors>true</TreatWarningsAsErrors><!-- 加下面2行,處理SA0001 --><GenerateDocumentationFile>true</GenerateDocumentationFile><NoWarn>$(NoWarn),1573,1591,1712</NoWarn></PropertyGroup>這個(gè)時(shí)候再build,就不會(huì)有錯(cuò)誤了。
對(duì)于這么簡(jiǎn)單的一個(gè)空項(xiàng)目,都有不少要修改的地方,就可以知道,默認(rèn)的規(guī)則是比較嚴(yán)格的。那么我們有沒(méi)有辦法避免應(yīng)用某些規(guī)則呢?答案是肯定的。
我們可以通過(guò)添加代碼分析規(guī)則集來(lái)自定義。
有兩個(gè)方式添加,一個(gè)是直接添加新建項(xiàng);一個(gè)是通過(guò)修改分析器里面的規(guī)則集嚴(yán)重性,修改后會(huì)自動(dòng)生成。
下面我們通過(guò)修改兩個(gè)規(guī)則來(lái)體驗(yàn)一下。
一個(gè)是不想要上面的頭部(SA1200),一個(gè)是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"> <!-- Using statements must be inside a namespace --><Rule Id="SA1200" Action="None" /><!-- The file header is missing or not located at the top of the file --><Rule Id="SA1633" Action="None" /> ? ?</Rules></RuleSet>同時(shí),還要修改csproj文件
<PropertyGroup><!-- other... --><TreatWarningsAsErrors>true</TreatWarningsAsErrors><!-- 加下面2行,處理SA0001 --><GenerateDocumentationFile>true</GenerateDocumentationFile><NoWarn>$(NoWarn),1573,1591,1712</NoWarn><!-- 加下面這行,自定義代碼分析規(guī)則集 --><CodeAnalysisRuleSet>..\test.ruleset</CodeAnalysisRuleSet></PropertyGroup>去掉代碼的頭部,和把using放到外面,再build一下項(xiàng)目,就可以正常通過(guò)了。
既然可以自己定義,那么就必然有這樣一個(gè)問(wèn)題,每個(gè)人可能都會(huì)想把自己的習(xí)慣放開(kāi),這樣的話,這個(gè)規(guī)則就是一個(gè)透明的存在了!!
換句話說(shuō),必須要有一些硬性規(guī)定,必須要有一些取舍。我們可以向某些開(kāi)源項(xiàng)目借鑒,同時(shí)在他的基礎(chǔ)上做簡(jiǎn)單的添加刪除,個(gè)人覺(jué)得應(yīng)該可以適應(yīng)大多數(shù)的情況了。
下面放出幾個(gè)覺(jué)得不錯(cuò)的參考。
Autofac?目前我就是以這個(gè)為基礎(chǔ)的
EntityFrameworkCore
在代碼分析規(guī)則集的基礎(chǔ)上,還可以用Stylecop.json來(lái)微調(diào)某些規(guī)則的行為。
當(dāng)把SA1633恢復(fù)之后,提示的第二個(gè)選項(xiàng)就是添加Stylecop.json配置文件
添加之后,還要在csproj里面做設(shè)置
<ItemGroup><AdditionalFiles Include="stylecop.json" /></ItemGroup>關(guān)于Stylecop.json的具體配置,可以參考Configuring StyleCop Analyzers,這里不繼續(xù)展開(kāi)。
除了上面的辦法,還可以通過(guò)安裝擴(kuò)展StyleCop來(lái)處理。
安裝后,右擊項(xiàng)目的時(shí)候就可以看到StyleCop相關(guān)的菜單。
總結(jié)
在團(tuán)隊(duì)內(nèi)保持一樣的編碼風(fēng)格,并能在開(kāi)發(fā)過(guò)程中糾正相應(yīng)的錯(cuò)誤,這是編寫(xiě)可維護(hù)和可讀代碼的重要一步,同樣也是代碼審查的重要一步!
當(dāng)然,在團(tuán)隊(duì)內(nèi)推行這類規(guī)范,還是要多多聽(tīng)取團(tuán)隊(duì)成員的意見(jiàn),也要定時(shí)檢查規(guī)則是否需要更新,畢竟時(shí)代在進(jìn)步!只要達(dá)成一致,就是好規(guī)則,就應(yīng)該要遵守。
StyleCop是一個(gè)很不錯(cuò)的工具,用的好就是利器。可以把它和cli模板項(xiàng)目相結(jié)合,這樣創(chuàng)建的新項(xiàng)目就都“內(nèi)嵌”了一樣的規(guī)則了。
友情提示,在老項(xiàng)目添加這個(gè)要慎重,不然會(huì)有一陣陣酸爽。
相關(guān)文章
代碼審查工具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社區(qū)新聞,深度好文,歡迎訪問(wèn)公眾號(hào)文章匯總 http://www.csharpkit.com
總結(jié)
以上是生活随笔為你收集整理的用StyleCop规范团队代码的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇: 如何优雅的利用Windows服务来部署A
- 下一篇: 什么是量子计算机?用一个简单例子来解释