Where are the field and constant naming rules for c#?

Types, Methods, Properties, Namespaces, and Enums have rules.

I see a field naming rule for Java, but not for C#. Also I dont see one for constants.

Are these missing for C# or am I searching incorrectly for them?

Hello @StingyJack
First of all thank you for reaching out to us.
Can you please specify a bit better what kind of rules are you looking for?
When speaking about Java, do you mean RSPEC-116 and RSPEC-115 ? By naming guideline for fields in C#, do you mean the Microsoft guideline?
You are correct, those rules are not implemented for C#.

I can specify some kind of naming convention for all of the other types but not fields and constants.

A selection from any of the usual ones would be fine
camelCase
_underscoreCamelCase (preferred and the convention I see most often as it disambiguates between arguments and locals)
PascalCase
snake_case
ALL_UPPER
etc…

Fields and constants would not be held to the same rule, each would have its own. Like how the Java rules are done. Just because MSFT couldnt agree well enough to publish a guideline doesnt mean that other teams couldnt agree.

Hi @StingyJack,

Thank you for your suggestion. This rule is interesting and I totally agree that styling is important, however we can’t implement it for now. We currently focus our current efforts on vulnerabilities, bugs and maintainability issues, which leaves no time for styling and naming rules.

As you said, the rule could be configured in many different ways, which means that activating it by default would raise a lot of issues on the first analysis of many projects. So either we don’t activate these rules and hope that developers will do it manually, or we activate them and make SonarLint/SonarCloud/SonarQube more complex to configure.

We’ll come back to your suggestion once we have a better way to handle styling and naming rules.

Don’t hesitate to suggest more rules. We can’t implement all of them but we always appreciate your contributions :wink:

Cheers,
Nicolas

As you said, the rule could be configured in many different ways, which means that activating it by default would raise a lot of issues on the first analysis of many projects. So either we don’t activate these rules and hope that developers will do it manually, or we activate them and make SonarLint/SonarCloud/SonarQube more complex to configure.

I didnt say anything about defaults, the point you are making is going to be applicable to any rule. I dont see what that has to do with denying the request other than to prop up a straw man to give the denial more weight.

There is already an enum naming rule thats regex configurable (S2342), so clearly the ask is possible and probably has most (if not all) of the code needed available, and that one was not judged to make Sonar configuration overly burdensome. Why would you evaluate this request differently?

I’m asking for is a gap to be filled for C# rules (like it has been for Java.). Its a rather large gap because without it, the formats for other identifiers can be used in code and create confusion. I would do this myself, but SonarCloud does not allow for users to define rules.

Hi @StingyJack,

Then I must have misunderstood you, sorry about that. I thought you were listing different conventions which we could use as default. When I saw so many conflicting styles I deduced that the rule would make a lot of noise.

I will specify the rule right away if we can find a convention which is at the same time meaningful, i.e. not [a-zA-Z0-9_]+, and accepted by at least 80% of projects. By “accepted” I mean that developers will fix raised issues instead of disabling the rule, or stop using SonarQube/SonarCloud/SonarLint.

The fact that we have implemented some rules in the past does not justify us adding more of the same kind, or at least not with a high priority. Some rules don’t work for all languages, or we realized after implementing the first rules that the maintenance cost+bad user experience cost was higher than the value it was providing to most users.

Here is an example to give you an idea of what I am talking about. We analyze quite a few open source projets in order to see how our rules behave on real code. I looked at our last analysis and this is what I saw:

  • The C# version of rule S2342 raises less than 10 issues on most project. It maxes out at less than 200 issues on the dnspy project. We can deduce that it is accepted by 90% projects, and the user experience is not that bad for the remaining 10%.
  • The java version of rule S116 raises less than 10 issues on many projects, but it rapidly goes beyond, and for some projects it raises hundreds if not thousands of issues: JDK9 (~5000 issues) Jetty (~3000) open-cms-core (~7000)… The PHP version of this rule raises even more issue so we could not activate it by default.

If the C# version of S116 behaves like the PHP one, we won’t be able to activate it by default. It would then be invisible to most users.

My goal here is not to deny a given rule. The rules you suggest make sense for most projects. It is all about managing expectation. As any company we have limited development resources, so if we have to chose between implementing a rule which will have little impact and improving our null pointer detection engine, the second option will be chosen. It doesn’t mean that the rule won’t be implemented one day.

Does this answer your question? Do you know conventions which we could follow for rules RSPEC-116 and RSPEC-115 and will be accepted by 80% projects?

Those were examples of the common identifier naming patterns that could be offered, but there is no intention to force either of them. It’s just easier to offer something like that than it is to ask us to always specify a regex like the Enum rule does

The one that will be the most accepted will be the one that meets everyone’s needs. Let us choose the naming conventions for fields and constants like we can for the Enums rule. This would make this rule more usable than some of the existing rules that dictate type and other identifier naming, but that do not match some teams’ conventions.

Furthermore, some of the existing rules have weird exceptions to them. like S100 (Methods and properties should be named in PascalCase) that doesnt enforce a necessary rule when any underscore is present, making things like public string this_should_be_a_violation {get;set;} allowable when it should not be. I (and others, no doubt) would like to avoid having these kinds of quality issues get by, so I would suggest that all the naming be configurable but with sensible defaults.

was my response not sufficient?

Hi @StingyJack

Thank you for the suggestion.
In order to be able to implement the rule we first need a rule proposal.

Can you please take a look at this comment with instructions from Nicolas and try to specify it first?

You can also take a look at specification from that issue RSPEC-5770 to see what’s generally needed. In shorthand:

  • Name of the rule
  • Message
  • Proposal of other fields: highlighting (no secondary location in this case). severity, impact,likehood, sonar way?
  • Description
  • C# Compliant and Noncompliant example (see Sub-Tasks section of the RSPEC)
  • VB.NET Compliant and Noncompliant example (see Sub-Tasks section of the RSPEC)

After that we`ll review it and put in in Jira.

A lot of that documentation looks like something that Sonar needs to know about or cares about having around. I cant disagree with your reasons (they are yours and I dont know them), but your bureaucracy and paper trail is your business, and not something you should be burdening your users with having to spend time researching/learning about and then fulfilling. There is no reuse value in it for us to invest the time into learning that process and artifacts.

The two RSPEC’s that both you and @Nicolas_Harraudeau (his name does not come up in the tag list) have cited cover this already. The ask is that they be implemented for C#.