AV2201: Int32.Parse() vs int.Parse()

[bkoelman]

The current rule is worded:

Use C# type aliases instead of the types from the System namespace (AV2201)

For instance, use object instead of Object, string instead of String, and int instead of Int32. These aliases have been introduced to make the primitive types first class citizens of the C# language, so use them accordingly.

Exception: When referring to static members of those types, it is custom to use the full CLS name, e.g. Int32.Parse() instead of int.Parse(). The same applies to members that need to specify the type they return, e.g. ReadInt32, GetUInt16.

So the rule currently prefers Int32.Parse() over int.Parse(), which is the opposite of the .editorconfig default and this StyleCop rule. The C# ECMA spec used to advocate for int.Parse() over Int32.Parse(), but that guidance was removed in later versions.

The last line of the exception must be kept for CLS compliance, but as far as I know the static member access is just a matter of taste without any technical consequences.

There is nothing wrong with having this preference in itself, but I thought I'd bring it up for reconsideration.

[bkoelman]

And it clashes a little bit with the rule below:

Prefer language syntax over explicit calls to underlying implementations (AV2202)

[dennisdoomen]

Ironically, I've never used String.Parse. Only string.Parse. So I'm fine to change it.