关键词搜索趋势,上海网站排名seo公司,照明网站模板,wordpress 网站生成app前言编码风格#xff0c;每个人都是有不同的特点#xff0c;风格各异#xff0c;而且一个人在不同的时期#xff0c;编码风格的差异也可能是非常大的#xff0c;好比学生时代#xff0c;刚工作的时候#xff0c;工作一段时间后等。在一个团队中#xff0c;或一个项目中… 前言编码风格每个人都是有不同的特点风格各异而且一个人在不同的时期编码风格的差异也可能是非常大的好比学生时代刚工作的时候工作一段时间后等。在一个团队中或一个项目中如果出现了N种风格这个可能就是比较头疼了尤其是风格差异很大的时候。一个项目一种风格或许还可以接受如果一个项目风格都不一样那就有点难受了就更不用说整个团队的了。长久来看团队之间难免会有人员的调动所以统一整个团队的编码风格还是很有必要的。统一了编码风格会带来什么好处呢下面列出几点便于代码审查新人(新同事/跨项目组同事)接手不会觉得杂乱无章...下面来先看看本文的重点StyleCop。什么是StyleCop这里引用维基百科的介绍StyleCop is an open-source static code analysis tool from Microsoft that checks C# code for conformance to StyleCops recommended coding styles and a subset of Microsofts .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:DocumentationLayoutMaintainabilityNamingOrderingReadabilitySpacing简单理解开源的静态代码分析工具用来检查代码是否符合推荐的编码风格。它的开源地址: https://github.com/StyleCop/StyleCop其在README的最后建议我们(使用Visual Studio 2015或更高版本的开发人员)使用的是StyleCopAnalyzers。所以后面我们用到的是它StyleCop规则基于.NET编译器(Roslyn)的实现。下面通过一个示例来介绍它的简单使用。示例当我们新建一个.NET Core的控制台程序之后大致就是下面的样子。可以看到是没有任何警告的。通过Nuget安装StyleCop.Analyzers或直接在csproj里面加下面的内容。ItemGroupPackageReference IncludeStyleCop.Analyzers Version1.1.1-rc.94PrivateAssetsAll/PrivateAssets/PackageReference/ItemGroup在回到Program.cs马上就可以看到有波浪线了~~这个时候我们需要狠一点把项目的所有警告级别的提示都当成错误来看待。PropertyGroup!-- other... --TreatWarningsAsErrorstrue/TreatWarningsAsErrors/PropertyGroup加了这个之后编译就立马出错了。在编译不通过时还是ERROR级别的错只能乖乖的去改了。按照提示一个个修改之后还是有一个SA0001的错误提示。要修复这个问题需要参考这个文档 SA0001.md启用一下生成XML文档同时加几个禁止显示的警告即可。PropertyGroup!-- other... --TreatWarningsAsErrorstrue/TreatWarningsAsErrors!-- 加下面2行,处理SA0001 --GenerateDocumentationFiletrue/GenerateDocumentationFileNoWarn$(NoWarn),1573,1591,1712/NoWarn/PropertyGroup这个时候再build就不会有错误了。对于这么简单的一个空项目都有不少要修改的地方就可以知道默认的规则是比较严格的。那么我们有没有办法避免应用某些规则呢答案是肯定的。我们可以通过添加代码分析规则集来自定义。有两个方式添加一个是直接添加新建项一个是通过修改分析器里面的规则集严重性修改后会自动生成。下面我们通过修改两个规则来体验一下。一个是不想要上面的头部(SA1200)一个是using可以在命名空间外面(SA1633)。下面是示例代码。?xml version1.0 encodingutf-8?RuleSet NameDemo Analyzer Rules DescriptionAnalyzer rules for Demo. ToolsVersion15.0Rules AnalyzerIdStyleCop.Analyzers RuleNamespaceStyleCop.Analyzers !-- Using statements must be inside a namespace --Rule IdSA1200 ActionNone /!-- The file header is missing or not located at the top of the file --Rule IdSA1633 ActionNone / /Rules/RuleSet同时还要修改csproj文件PropertyGroup!-- other... --TreatWarningsAsErrorstrue/TreatWarningsAsErrors!-- 加下面2行,处理SA0001 --GenerateDocumentationFiletrue/GenerateDocumentationFileNoWarn$(NoWarn),1573,1591,1712/NoWarn!-- 加下面这行,自定义代码分析规则集 --CodeAnalysisRuleSet..\test.ruleset/CodeAnalysisRuleSet/PropertyGroup去掉代码的头部和把using放到外面再build一下项目就可以正常通过了。既然可以自己定义那么就必然有这样一个问题每个人可能都会想把自己的习惯放开这样的话这个规则就是一个透明的存在了换句话说必须要有一些硬性规定必须要有一些取舍。我们可以向某些开源项目借鉴同时在他的基础上做简单的添加删除个人觉得应该可以适应大多数的情况了。下面放出几个觉得不错的参考。Autofac 目前我就是以这个为基础的EntityFrameworkCore在代码分析规则集的基础上还可以用Stylecop.json来微调某些规则的行为。当把SA1633恢复之后提示的第二个选项就是添加Stylecop.json配置文件添加之后还要在csproj里面做设置ItemGroupAdditionalFiles Includestylecop.json //ItemGroup关于Stylecop.json的具体配置可以参考Configuring StyleCop Analyzers这里不继续展开。除了上面的办法还可以通过安装扩展StyleCop来处理。安装后右击项目的时候就可以看到StyleCop相关的菜单。总结在团队内保持一样的编码风格并能在开发过程中纠正相应的错误这是编写可维护和可读代码的重要一步同样也是代码审查的重要一步当然在团队内推行这类规范还是要多多听取团队成员的意见也要定时检查规则是否需要更新毕竟时代在进步只要达成一致就是好规则就应该要遵守。StyleCop是一个很不错的工具用的好就是利器。可以把它和cli模板项目相结合这样创建的新项目就都“内嵌”了一样的规则了。友情提示在老项目添加这个要慎重不然会有一阵阵酸爽。相关文章代码审查工具StyleCopStyleCop: A Detailed Guide to Starting and Using ItAutomated, portable code style checking in .NET Core projects原文地址https://www.cnblogs.com/catcher1994/p/10375823.html.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com
