The future of StyleCop?

[stylecop]

The future of StyleCop?

[adamralph]

Imagine these scenarios:

---

You decide to contribute to project Foo. You make some changes. Your local build is green so you send a PR. The PR build fails due to a load of static analysis errors. You find out (hopefully via some "how to build" docs") that you need analysers, X, Y and Z installed in VS and you must run them with configs A, B and C. You grit your teeth and install all that, configure it, run the analysis, fix up your PR and your PR build is green.

You decide to contribute to project Bar. You make some changes. Your local build is green so you send a PR. The PR build fails due to a load of static analysis errors. You find out (hopefully via some "how to build" docs") that you need analysers, U, V and W installed in VS and you must run them with configs D, E and F. You curse yourself for not checking what analyser installations and configs this new project needs before sending the PR, but nevertheless you are determined to carry on so you install all that, configure it, run the analysis, fix up your PR and your PR build is green.

You take a look at project Baz and decide not to contribute because you're fed up of installing and configuring analysers in VS.

vs.

You decide to contribute to project Foo. You make some changes. Your local build is green so you send a PR and the PR build is green.

You decide to contribute to project Bar. You make some changes. Your local build is green so you send a PR and the PR build is green.

You decide to contribute to project Baz...

...and so on.

---

In the latter case, the projects all had the static analysers installed in source and errors were reported while you were writing the code.

[meh-uk]

Sounds good.

[jimmyheaddon]

Seems perfectly reasonable to me, future effort is better spent on DotNetAnalyzers/StyleCopAnalyzers.

Given this project has been stagnate for such a time, any Visual Studio <= 2013 consumers should have adjusted to the fact that new rules and fixes will not be released. Therefore, the stylecop-resharper repo you mention will allow them to continue running until JetBrains make any breaking changes to the ReSharper API.

[JimBobSquarePants]

👍 From me. For my, and I would imagine many others, just now it's a case of just getting something working for Resharper 9.2+

[antonio-gil]

Sounds reasonable, considering that from VS2015 and onwards Roslyn analyzers and rules could make (great) part of the job.

[jizc]

I'd like to add that for Unity3D developers like myself, StyleCopAnalyzers doesn't really work that well. So for me it's awesome that this project exists and I'm looking forward to a release that also supports StyleCop+.

[citizenmatt]

What's the problem with StyleCopAnalyzers + Unity3D? Lack of VS2015?

[jizc]

I believe the main problem comes when using Visual Studio Tools for Unity3D and the configuration file stylecop.json (detailed in Configuration.md). The configuration file needs to be added to the .csproj file, but the .csproj file gets overwritten every time Unity3D compiles. Unity3D solutions also traditionally includes 2 projects (one regular and one for editor scripts) and it's pretty annoying to have to maintain two rule set files in addition to continually fixing the two .csproj files. After a few hours of trying to get it to work on a single Unity3D project I finally gave up. When using the old ReSharper plug-in for StyleCop everything was plug-and-play, all one had to do when starting a new Unity3D project was to copy the Settings.StyleCop file to the root of the project and you where ready to go.

[childnode]

@zynthar I think we're getting off topic but: you are aware of the "plugin mechanism" of the VS Tools for Unity? like

ProjectFilesGenerator.ProjectFileGeneration += (solutionFileName, solutionFileContent) => { return DoYourManipulation(solutionFileContent); };

where you can manipulate the generated project file, e.g. with XDocument. I don't think Resharper Plugin will ever help here?

[citizenmatt]

Where does that code live? In a Unity editor plugin?

[childnode]

Yes, as described on the linked documentation, you can just write your own (static) editor class and add a custom hook / delegate callback for the Unitytools event ProjectFilesGenerator.ProjectFileGeneration
If it's in Dll beneath an Editor folder or just a .cs file in the folder doesn't matter. Typically UnityVS is imported into Assets/UnityVS/Editor

Warning: all this is based on 4.x releases, Starting from Unity 5.2 (I think) the UnityVS third party is no more needed but built in, so perhaps details may change. Not yet tested it.

[cabadam]

A little late, but throwing my two cents in - my initial thoughts on the StyleCopAnalyzers project is that it will be harder to use. Our environment is such that we have many solutions with many projects. Some projects are shared between solutions (common libraries), but others are unique. Having to add a nuget package to each and every one of them to enforce Stylecop rules is unfortunate. Right now, we just use the Resharper extension plus a Stylecop rules file sitting at one of the top level folders of source control and it automatically applies to everything.

We would prefer not to have "yet another thing" to remember when we setup a new solution and/or project. That seems like it will be error prone.

[meh-uk]

But if you want to enforce Stylecop warnings as errors on a project by project basis you have to do something with a new project anyway.

And if you want developers to start writing good new code from now on you have to do something like that where possible.

I'm sure you can write a build step into your CI system to enforce that all projects have the StyleCop Analyzers package if you wanted.

[cabadam]

Currently, we don't enforce as errors. We have a pseudo-large 'legacy' code base that predated Stylecop and used very different style rules. We don't have the time to go through in a large chunk and migrate everything.

Right now, we basically operate under a policy that all new code needs to be compliant. Pre-existing code does not need to be compliant, but we tell developers if they go into a file to make more than a small "one-line" type change, that the file should be updated for the new rules.

We're getting there, but not there yet. Someday, yes, all of our code will be updated and enforcing as errors would then be a good option.

And sure, we could try to enforce the package at the CI level, just not quite as easy as now where it is even a concern.

[jizc]

@childnode Thanks for the tip!

[adamralph]

I given this some time stew in my mind and I believe there is no point putting further effort into StyleCop. Roslyn based analysers will dominate the future and I think it's worth joining in on the effort at https://github.com/DotNetAnalyzers/StyleCopAnalyzers for anyone interested in this space.

As far as https://www.nuget.org/packages/StyleCop.MSBuild/ is concerned, I'm happy to leave it listed and even push out a new version if at some point someone does produce a new version of StyleCop, but at that point I'd probably offer the control of https://www.nuget.org/packages/StyleCop.MSBuild/ to that person/group.

I do think it is important that https://github.com/DotNetAnalyzers/StyleCopAnalyzers has an equivalent story as StyleCop.MSBuild offers StyleCop. This doesn't necessarily have to have anything to do with MSBuild. The analysis must be able to run independently of local tooling (not require installations of VS add-ins, for example), be carried with the source (via a NuGet package restore) and must run equally well on build servers.

[AdjutantML]

Agreed, this is the right way to go (StyleCopAnalyzers)

Two thoughts / questions:
1 - Like @cabadam we also use a single 'coding standard' ruleset (stylecop.settings) to apply StyleCop and StyleCop+ rules to all projects. While project specific customization is a bonus, we use in-code rule suppression attributes as necessary. Why is a VS extension a bad thing? (i.e. The project based NuGet approach requires installation (web access) for clean project checkouts, and bloats project structures with StyleCop files (and actually duplicates them) for each project)

2 - Since we currently make extensive and customized use of SA and Advanced naming (stylecop+) rules, would it be feasible (even possible) to attempt converting this all to the new configuration file (JSON / ruleset combo) format? - i.e. Will it be possible to convert advanced naming rules without having to write new rules?

[adamralph]

The project based NuGet approach requires installation (web access) for clean project checkouts

This is no different to any other NuGet package. I'd hazard a guess that the number of projects that do not use some NuGet package these days is vanishingly small. If you can't download and restore those other NuGet packages, then you can't build the project, so the StyleCop VS add-in is of little use in that scenario.

bloats project structures with StyleCop files (and actually duplicates them) for each project)

There is little bloat. Installation of StyleCop.MSBuild adds a few lines to the csproj. This is all handled by NuGet and does not require any manual editing. The same applies for Roslyn analyzers.

Why is a VS extension a bad thing?

I wouldn't call it bad, but I think a NuGet approach is superior, both for StyleCop and Roslyn analyzers. By using NuGet, your code rules and the static analyzers that enforce them are carried with that source wherever it goes. The analysis will run on every build on every machine regardless of local installations. All developer will see the results, without having to craft their own development environment specifically to that project's standards. The analysis will run on build servers without having to craft specialised build steps which may even involve having VS on the machine, etc.

[AdjutantML]

Thanks for feedback.
I'll give the NuGet approach another proper unbiased attempt.

However the project based vs. environment based setup still seems unconvincing.
Ideally, StyleCop configuration should be performed once (per environment), and be able to run it on every project from there on (new or existing), without having to perform additional configuration.

If I'm understand correctly, your suggestion is that the once-off configuration effort (for each project) is justified and worth it?

[cabadam]

Something else you can do: If you go actually download the source for StyleCopAnalyzers, you'll find in it a VSIX extension project already exists. We have been using that to skip the Nuget process. Everything Visual Studio needs to properly perform the analysis is either already installed (via the VSIX), or in source control.

That just leaves the per-project vs per-environment issue. Unfortunately, there is no good way around it that we can identify. Each project still has to be individually setup to point to a stylecop.analyzers.ruleset file, and potentially a stylecop.json file as well if additional tweaks are needed (we have both).

To help simplify the process, we wrote a small tool that runs as part of our CI process. If "get source code" is step 1 of an automated build, then this is step 2. It immediately scans all .csproj files to ensure the proper ruleset and json file is present. If not, the build immediately fails.

It still isn't ideal, because a developer might have been working on a new project for a bit before pushing it into source control, and so might have forgotten to add the settings files, and might have done things that is against the style rules in the mean time, but at least there is an automated process to catch it once it attempts to build.

[adamralph]

I'm a firm believer in static analysis living with source code and being part of the native build script (csproj).

Less to set up

Install once in source and commit

vs.

Install in every environment (developer workstations, build agents, etc.) both current and future.

More reliable

A guarantee that the analysis is run every time and everywhere the project is built

vs.

Relying each environment to be properly set up. E.g. a new build agent may have an incomplete environment, a new developer forgetting to follow the environment set up guidelines, an existing environment regressing, etc.

Easier to run

Having the analysis run on every single build whether in VS or using MSBuild directly

vs.

Having to write build config steps to run the analysis, or asking developers to run build scripts which run the analysis or right click the extension in VS before committing, etc.