C++ / S116: Discriminate naming conventions for classes and structures fields

Rules and Languages New rules / language support
, ,
1

Hello,

In C++, for classes members, our naming convention is:

class MyClass
{
public:
    void Foo() { ++myMember; }
private:
    int32_t m_myMember;
};

The purpose of the m_ prefix is to discriminate member variables of local variables in member functions. But in a C structure, it doesn’t make sense. So the naming convention is then:

struct MyStruct
{
    int32_t MyMember;
};

But there is only one rule for classes and structures, so only one regular expression: S116.
Would it be possible to add a new rule to discriminate these two cases ?

Note there are two different rules to name the class/struct: respectively S101 and S1642.

9

Hi @Oodini,

We are aware that our rule for naming convention is limited. But we are afraid of opening the Pandora box, requiring different conventions for:

  • struct vs class
  • public vs protected vs private (by the way, isn’t it a better criteria than struct vs class?)
  • const vs mutable
  • bool vs other type
  • static vs non-static (some people require isXxx, other forbid it, other don’t care)
  • Of a type matching a class template argument or not

If we allow the user to customize all the possible combinaisons, it means 48 rules (or one rule with 48 regex parameters). It could technically be done, but is probably not the best user experience.

Another option would be to allow to select between a closed set of common practices, but then again, we could not find a set that we felt was generic enough to satisfy most of our users.

Add to that that many projects also follow different conventions in different parts of the project (in the UI part where I’m using Qt a lot, I use Qt convention, in the engine I follow the Unreal style, and for my embedded scripting language, I follow LLVM style guide).

As the joke goes, if you ask 20 C++ devs what is their naming convention, you’ll get at least 42 different answers…

So, finally, for now we are keeping our very basic rule. But we are open to changing it if we can come up with a better idea.

My goal with explaining how we reached the current situation is not to discourage changes, but on the opposite to open a discussion on how we could improve our naming convention rules for all users. So what do you think about that?

1 Like
10

Hello @JolyLoic ,

Thanks for your answer.

I’ll leave it to you to deal with whatever might come out of Pandora’s box. :slight_smile:
Some requests seem more reasonable to me than others. Fom my point of view, hungarian notation is so old-school… But it is only my opinion.

However, if users cannot exercise fine-grained control over naming policies, these policies will prove unusable and therefore pointless. People won’t change their coding conventions and code base just because you have limited rules. So these ones will be disabled. Although enforcing consistent naming conventions within a code base is actually of paramount importance.

I don’t work on Sonar code, but I guess once you created the rule S116, it musn’t be so difficult to naively offer a range of naming rules applied to different items in the AST. But…

I agree with you. Maybe we should have only one rule “Respect naming conventions”. The conventions, which may be complex, would be described in sonar-project.properties. This one enables to do hierarchical settings, so we can have detailled rules superseding other rules. But that may require to do a matching engine…

sonar.naming.enabled = true

# Defaults
sonar.naming.field.default = camelCase
sonar.naming.field.default.prefix =
sonar.naming.field.default.pattern = ^[a-z][A-Za-z0-9]*$

# Policy 10: private fields in classes => leading underscore
sonar.naming.field.10.when = visibility:private; containerKind:class
sonar.naming.field.10.prefix = _
sonar.naming.field.10.pattern = ^m_[a-z][A-Za-z0-9]*$

# Policy 20: public fields in structs => PascalCase (no underscore)
sonar.naming.field.20.when = visibility:public; containerKind:struct
sonar.naming.field.20.pattern = ^[A-Z][A-Za-z0-9]*$

So the user defines only rules he’s interested in.

Here are some ideas for filters:

  • symbol: field | method | type | parameter
  • visibility: public | protected | private | internal
  • containerKind: class | struct | enum | interface | union
  • isStatic: true/false
  • isConst: true/false
  • type: bool | integral | floating | string | other (ou typeCategory)
  • isTemplateArgDependent: true/false
2 Likes