• 用StyleCop规范团队代码


    https://marketplace.visualstudio.com/items?itemName=vs-publisher-599079.CodeFormatter

    前言

    编码风格,每个人都是有不同的特点,风格各异,而且一个人在不同的时期,编码风格的差异也可能是非常大的,好比学生时代,刚工作的时候,工作一段时间后等。

    在一个团队中,或一个项目中,如果出现了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

    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><PackageReferenceInclude="StyleCop.Analyzers"Version="1.1.1-rc.94"><PrivateAssets>All </PrivateAssets></PackageReference></ItemGroup>

    在回到Program.cs,马上就可以看到有波浪线了~~

    这个时候我们需要狠一点,把项目的所有警告级别的提示都当成错误来看待。

    <PropertyGroup><!-- other... --><TreatWarningsAsErrors>true </TreatWarningsAsErrors></PropertyGroup>

    加了这个之后,编译就立马出错了。

    在编译不通过时,还是ERROR级别的错,只能乖乖的去改了。

    按照提示,一个个修改之后,还是有一个SA0001的错误提示。

    要修复这个问题,需要参考这个文档 SA0001.md

    启用一下生成XML文档,同时加几个禁止显示的警告即可。

    <PropertyGroup><!-- other... --><TreatWarningsAsErrors>true </TreatWarningsAsErrors><!-- 加下面2行,处理SA0001 --><GenerateDocumentationFile>true </GenerateDocumentationFile><NoWarn>$(NoWarn),1573,1591,1712 </NoWarn></PropertyGroup>

    这个时候再build,就不会有错误了。

    对于这么简单的一个空项目,都有不少要修改的地方,就可以知道,默认的规则是比较严格的。那么我们有没有办法避免应用某些规则呢?答案是肯定的。

    我们可以通过添加代码分析规则集来自定义。

    有两个方式添加,一个是直接添加新建项;一个是通过修改分析器里面的规则集严重性,修改后会自动生成。

    下面我们通过修改两个规则来体验一下。

    一个是不想要上面的头部(SA1200),一个是using可以在命名空间外面(SA1633)。

    下面是示例代码。

    <?xml version="1.0"encoding="utf-8"?><RuleSetName="Demo Analyzer Rules"Deion="Analyzer rules for Demo."ToolsVersion="15.0"><RulesAnalyzerId="StyleCop.Analyzers"RuleNamespace="StyleCop.Analyzers"><!-- Using statements must be inside a namespace --><RuleId="SA1200"Action="None"/><!-- The file header is missing or not located at the top of the file --><RuleId="SA1633"Action="None"/></Rules></RuleSet>

    同时,还要修改csproj文件

    <PropertyGroup><!-- other... --><TreatWarningsAsErrors>true </TreatWarningsAsErrors><!-- 加下面2行,处理SA0001 --><GenerateDocumentationFile>true </GenerateDocumentationFile><NoWarn>$(NoWarn),1573,1591,1712 </NoWarn><!-- 加下面这行,自定义代码分析规则集 --><CodeAnalysisRuleSet>..test.ruleset </CodeAnalysisRuleSet></PropertyGroup>

    去掉代码的头部,和把using放到外面,再build一下项目,就可以正常通过了。

    既然可以自己定义,那么就必然有这样一个问题,每个人可能都会想把自己的习惯放开,这样的话,这个规则就是一个透明的存在了!!

    换句话说,必须要有一些硬性规定,必须要有一些取舍。我们可以向某些开源项目借鉴,同时在他的基础上做简单的添加删除,个人觉得应该可以适应大多数的情况了。

    下面放出几个觉得不错的参考。

    • Autofac 目前我就是以这个为基础的
    • EntityFrameworkCore

    在代码分析规则集的基础上,还可以用Stylecop.json来微调某些规则的行为。

    当把SA1633恢复之后,提示的第二个选项就是添加Stylecop.json配置文件

    添加之后,还要在csproj里面做设置

    <ItemGroup><AdditionalFilesInclude="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
  • 相关阅读:
    C# 中类重写 ToString 方法
    虚方法(virtual)和抽象方法(abstract)的区别
    C#的扩展方法学习
    C# .NET 和.NET Framework区别
    C#值类型和引用类型
    抽象和接口的区别和使用
    什么是委托?
    什么是继承?
    设计模式:单一职责原则
    Java 13,最新最全新特性解读
  • 原文地址:https://www.cnblogs.com/Leo_wl/p/15702386.html
Copyright © 2020-2023  润新知