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

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 © 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.

[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.

[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.