StyleCopAnalyzers VS Roslynator

Several well-known NuGet packages such as xUnit.net, FluentAssertions, StyleCop, Entity Framework Core, and others include by default a significant number of Roslyn analyzers. They help you adhere to the conventions and best practices of these libraries.

I created a StyleCopAnalysers.ruleset file at the root of my project, which contains the ruleset for analysis. The tool not only identifies issues but also attempts to fix them, providing a log of any unresolved problems. In addition to running the analyzer upon build, the dotnet format command also runs any external analyzers that it detects by default as well.

https://github.com/DotNetAnalyzers/StyleCopAnalyzers the successor to stylecop - most of the rules ported over

I'm a C# guy, so that is what I care about. For .NET we do have StyleCop analyzers. And EditorConfig exists to help at the IDE level across all languages. And git itself can be configured with such things as eol and autoclrf.

I'd also like to know how to clean up based on rules like SA1507 - never more than one blank line in a row, and related rules to remove blank likes after { and before }

StyleCop is from Microsoft: https://github.com/DotNetAnalyzers/StyleCopAnalyzers

Using their own APIs, Roslyn Analyzers verifies certain conditions about the source code and, if necessary, feeds back into the compiler in the form of compilation warnings and errors. An example would be StyleCop.

StyleCop.Analyzers

- StyleCopAnalyzers but I wasn't able to find an official CLI tool?

There's also this project https://github.com/JosefPihrt/Roslynator that can add even more analyzers.

It does. Nearly every style guide I've seen for any language that allows this prefers this style. I personally prefer it when such structures are needed, but would suggest following it just for consistency and the practical benefits.

Roslynator.Analyzers

The reason I say 'similar' above is that though you may treat it as production code, there are some things in the nature of writing tests that may require different coding standard to be enforced. A good example of this is the RCS1046 analyzer, enforcing names of asynchronous methods to be suffixed with 'Async'; in this case it would be acceptable to override this rule (with an .editorconfig for example) so that you're method name continues to describe the behaviour of the application, and we don't have tests named like public async Task My_descriptive_method_name_async().

You can write Roslyn analyzer but you can also simply use this set of analyzers: https://github.com/JosefPihrt/Roslynator. It has analyzers for both async method not ending with Async and non-async methods ending with Async.

My suggestion is to look into installing Roslynator or Sonarlint. Both are free and work with either Visual Studio or VS Code. With them you can right click on your solution and Run Analysis and it will give you a list of "code smells" and automatic fixes for many of them. They are great tools for any dev.

Roslynator while not exactly as good as full R# does a pretty good job for the analysis and refactoring hints imo. Paired with Intellicode + NCrunch (paid) so far has been a good enough experience for us.

I prefer the second and roslynator would give RCS1124: Inline local variable1 for the first one.

Roslynator.Analyzers