Clarified the use of var (AV1520) and supplemented AV1707 (names)

[bkoelman]

AV1520 This PR does not fundamentally change the point of view around var usage. But it makes the examples compatible with automated tooling (vanilla Visual Studio, Visual Studio with Resharper, Rider). Automation is not a requirement, but it should at least be possible (which goes for the majority of rules).

Built-in types are always short, so spelling out the type name does not clutter the screen with useless information, which may happen on deeply nested generic types (IOrderedEnumerable<IGrouping<...>>).

The "when evident" mode is conservative in nature, only using var when definitely obvious and falling back to full type names when unsure or unable to determine. This means that treating var usage manually on a case-by-case basis (effectively allowing var in more cases than in the automated case) yields more readable code. But at the expense of recurring subjective discussions around var usage in PRs, which is a tradeoff every team can make for itself.

AV1707 When using var, some developers tend to suffix each variable name with its type, which is an anti-pattern (similar to Hungarian notation). Because this manual effort deteriorates over time, similar to outdated documentation that states the obvious. When the type changes due to refactorings elsewhere, you'll need to remember to also rename the affected variables, which is often forgotten, and then the code becomes misleading. Therefore it is preferred to rely on type information that gets validated by the compiler.

[dennisdoomen]

Time to merge?

[bkoelman]

Yes