C/C++ field naming convention rules for public/private, static, constant, etc

From what I can tell, there is only one field naming convention rule for the C and C++ languages. However, some of the other languages, like Java, let you specify different naming conventions for fields for when they are public/private constants, static/non-static, etc.

It would be nice if the SonarCFamily plugin had the same field naming convention rules as the SonarJava plugin.

Rule suggestions:

  • severity: Minor
  • tags: convention
  • type: Code Smell


You are right that currently, for C and C++, we only have one naming convention for all fields, whatever the field properties. This could be improved, but the design space is indeed pretty large, and since it’s hard in C++ to find two projects that agree on naming conventions, we cannot rely on well established conventions to guide us.

For instance, when concentrating of field only, there are those dimensions:

  • Accessibility (public, protected, private)
  • Anything related to constness : const, volatile, constexpr, mutable
  • static or not
  • dependant on a template parameter or not
  • some stuff related to type. I’m not advocating hungarian notation, but some people do. Or more reasonably, I’ve seen projects using different conventions for bool (myColor, mySize, vs isEmpty, isVisible) or maybe for bitfields.
  • ownership mode when the field is a pointer (non-owning, shared ownership, unique ownership)

There might be more, but just considering those, we can already have 3*4*2*2*3*3=432 naming conventions, just for fields :blush:

So before proceeding further, it would be interesting to know which of those parameters you consider relevant to establish a naming convention. And first question (I’m opening a poll, so that other people may give their opinion):

  • One naming convention for all fields is enough
  • I want to be able to have different naming conventions for different kinds of fields

0 voters

Another point of interest is the way to define a naming convention. Currently, we are based on regex. Is this the good way to specify those, or would you prefer something more like prefix + (camelCase|snake_case|PascalCase) + suffix?

  • Regex
  • Prefix + case + suffix
  • I don’t care

0 voters