AV2201 C# keyword over type name

[ygoe]

While I don't agree with the exception you provided (do use the type name for static method calls) for its inconsistency, I have another addition for this one:

Do use the type name as part of method names like for example ReadInt32() or GetUInt16() as in BinaryReader-like classes. These methods may be called from other CLS languages that don't know about C# type keywords. It's obvious to use a name like ReadString instead of Readstring (notice the case difference).

[dennisdoomen]

That one used to be part of the guidelines 😕. I recall removing it at some point because Static Analysis already covered that one.

[ygoe]

Now I've seen that you reference that Static Analysis thing from Visual Studio. Is it a replacement of FxCop? I've downloaded and used FxCop once recently so it still seems to exist.

But I have a deep mistrust of FxCop and StyleCop because they're so unbelievably dumb. These tools just don't understand code but try to make rules how to write it. I ended up disabling a lot of the rules to make the output more acceptable but still had to ignore many warnings in most (not all!) of the places. That was a one-time action that really did find a single minor bug (out of thousands of messages) and I certainly won't do it again very soon.

My impression is that these tools are an effort to enforce clean code where the developers can't write clean code themselves. But since the tools are so primitive, the rules must be simple as well. Any more intelligent order cannot be recognised and is thus rejected as false. Which I disagree with. People who are able to clean up after them won't need the tools very much. (They, too, make mistakes, but will hardly find them in all this warning noise. Unit tests are probably better for that.) And those who can't will be annoyed by them as well. No machine can replace a human code review. If that would be possible, machines could write the code in the first place.

We write these rules to guide reviewers (and programmers). And they know how to interpret them or even when to ignore them for good reason.