Sonar-dotnet: Update S100: Relax the rule restrictions

[fmallet]

Source:
http://stackoverflow.com/questions/42759665/does-sonarlint-have-the-custom-dictionary-feature-like-the-fxcop

[Evangelink]

No longer needed since fix #577

[SierraNL]

I would still like to see this opened again, since there are more usecases then the two character acronym mentioned.

For instance:
In most companies I've worked for, the company name which is an acrynom, is supposed to have capital casing. This was added to a CustomDictionary.xml for fxcop/CA in the past.

If I would want to add SonarQube analysis to a codebase like that, I would have to turn off the rule, or edit every code file in the project, since these acronyms are in every namespace.

There are more reasons to have casing exceptions, and currently there is no nice solution, while there was one in the FXCop / CA era.

[andrei-epure-sonarsource]

I am reopening this as it seems it is something wanted by our community. We may not necessarily fix this by supporting custom dictionaries, but maybe a different approach (like allowing acronym-like portions inside the name). Also, we may decide to close it again (I'm reopening it to bring it back into discussion internally)

[andrei-epure-sonarsource]

Result of an internal discussion:

Let's relax the rule as "method name has to start with an uppercase letter, not be fully uppercase and not contain underscores". There will always be somebody adding longer acronyms, ex: NIIOMTPLABOPARMBETZHELBETRABSBOMONIMONKONOTDTEKHSTROMONT

[andrei-epure-sonarsource]

I am changing the scope of the initial ticket which was from 2017. Such an old ticket should generally be closed as won't fix.

By relaxing the restrictions, we'd be less noisy and our users wouldn't complain that much. Moreover, we don't plan to be a styling tool, so we'd raise on really obvious bad cases.

[andrei-epure-sonarsource]

RSPEC-100

SonarWay
Default Severity:Minor
Impact:Low
Likelihood:Low