Stylecopanalyzers: File headers: allow pattern matching or multiple allowable headers to support headers that must include a date

[oatkins]

I agree with @sharwell that it's a pain to have a file header that includes a date. However, this might not always be avoidable. On one project, the header includes the _year_ when the file was last updated.

It would be helpful if there was a way to allow, say, "Copyright (C) Flubbersoft, {year}" where year is defined as

\d{4}

(regular expression) or even

{ "2014", "2015" }

(array of permissible values)

I can make my own analyzer for this case if it's rare, but would be interested to know whether it would be helpful to anyone else too.

[sharwell]

So what you're saying is, if you update all the headers to say 2015, it will still be correct?

Because that's exactly what I did in my work project to handle exactly this case. :smile: And with all of them the same, I can define a variable "year": "2015" which is referenced in the copyright text as {year}.

[oatkins]

We were asked not to update the date unless the file had been changed.

[oatkins]

Of course, if you _do_ update the date, then the file has definitely been changed... but I don't think that's what was meant ;-)

[mreu]

+1 Same here.

[brenank]

We have the same issue. We don't update the date unless the file has been changed. With a large solution, changing all file headers to a new date is cumbersome.

Having a way to support this use case would be very helpful.

[sharwell]

At this point, the project already supports two specific and particularly practical use cases:

1. Cases like the .NET Foundation uses, which minimizes the chances that a project header ever needs to be changed (no date included at all, but instead references another file containing the information).
2. The strongest possible copyright protection under US copyright law, which is to use the year in which the project started as the copyright date and not change the year for future files (new files get back-dated).

I've seen other strategies employed, but they all seem to lose sight of the actual goals. When 95 years rolls around, one of three things will inevitably happen:

1. You don't care about the code enough to try and protect it anymore
2. The code is so old no one cares to copy it anymore aside from fair use for historical preservation purposes
3. We will all be dead so the whole thing is moot

My recommendation is to use the inflexibility of this tool as rationale to change the policy as it applies to your project. The company where I work tends to be especially inflexible on this subject, yet for this exact reason we ended up allowed to make this change on the C# projects.

[Nihlus]

Aside from dates, a pattern matching feature would be very useful in terms of headers where the file author is included - a common pattern in open-source collaborations. As it is, having two files with the same header where the only difference is the author (or list of authors) is not possible. A way to have wildcards or list value matching would solve this issue.

[sharwell]

@Nihlus When extending this feature, I'm looking for two critical characteristics:

1. The ability to look at the text of a source file and determine that the header is either correct or the header is not correct.
2. In the event the header is not correct, a code fix is provided that will modify it such that the analysis determines the header is now correct.

[Nihlus]

@sharwell To me, then, it makes sense to extend the existing variable system in the json configuration to allow lists of values, along with a default value for the code fix. That solves the mentioned issue, and maintains the rigidity of the rule.

[d-ng]

We are running into the same issue and are really hoping there is a fix for it. Any update on this?

[sharwell]

@d-ng See https://github.com/DotNetAnalyzers/StyleCopAnalyzers/issues/1357#issuecomment-264579971, especially the final paragraph. This approach has proven quite good at improving higher-level developer workflows, and there isn't any clear advantage to undermining its ability to do so.

[d-ng]

@sharwell: no luck on changing company policies after repeatedly pushing back. There had been teams that had to go back and revisit all the files over the years to change the years on copyright headers. So the copyright header rule is effectively unusable to us unless some flexibility is added in the variable system.

[jessekingf]

@sharwell: Any updates on this? It is a company requirement for me to have the copyright year in the file header (year the files was created). With the year hard coded in the stylecop config it makes it very hard to have a mix of years.

Has a general design for this been discussed?

[sharwell]

This change would not meet the ideal outcome we expect for StyleCop Analyzers automation (validation without false positives or false negatives, and the ability to fix everything automatically without introducing errors). In addition, the current implementation supports the requirements of a wide variety of organizations, including but not limited to the .NET Foundation's guidance and Microsoft for its own internal projects.

If a project falls outside the capabilities of StyleCop Analyzers for header validation, I would recommend creating a new analyzer for use in validating file headers for that project. It should not be difficult to implement considering StyleCop Analyzers is open source under a permissive license, and the new testing library (Microsoft.CodeAnalysis.Testing) is flexible and easier than ever to get a project working. There are many options for deployment of the result, including the following:

1. Publishing on NuGet
2. Publishing on an internal-only NuGet feed
3. Inclusion of the analyzers as source within the repository itself, similar to how dotnet/machinelearning has https://github.com/dotnet/machinelearning/tree/master/src/Microsoft.ML.Analyzer