https://rules.sonarsource.com/cpp/RSPEC-1543 mandates that macros use
MACRO_CASE. If we assume for a moment that we have a good reason to not enforce corresponding rules about naming conventions for every other kind of symbol, then the inverse rule could be useful.
Anything that is not a macro should not use
MACRO_CASE because syntactically, macros behave differently from other kinds of names. When a macro is defined in a translation unit, the same name is effectively banned for the entire rest of the translation unit. If all macros are correctly using
MACRO_CASE then the simple solution to naming conflicts resulting from this problem is to avoid using that case.
Thank you for your suggestion. Why have a single rule (non-macro naming convention), if you can have multiple?
S1878 - unions
S1642 - structs
S2342 - enums
S101 - classes
S2304 - namespaces
S2343 - enum values
S3222 - labels
S116 - fields
S6193 - coroutines
S6221 - concepts
S100 - functions (including member functions)
S1578 - files
S117 - local variables and function parameters
- (not implemented yet) - template parameters
- (not implemented yet) - global variables
This list should cover all non-macro identifiers. Please let me know if it misses something.
I have created a ticket CPP-3747 to complete the coverage (the “not-implemented” in the list above).
To avoid a name clash, make sure to configure these rules with a regular expression that does not intersect with your macro-names expression (S1543).
We use different naming conventions for class member variables depending on access specifier, which I think the primary reason why don’t use all the provided rules. Granted, I don’t think that is the area where we are most likely to run into this case being used, but is is an example of lack of granularity.
I think clang-tidy does a better job at granularity in this space, with its very long list of options for the readability-identifier-naming check : clang-tidy - readability-identifier-naming — Extra Clang Tools 14.0.0 documentation This probably over the top for most use cases, but should act as a frame of reference.
But also, all of these rules are positive constraints. The special nature of macros could justify a negative constraint.
My guess is that usage of
MACRO_CASE has leaked into global constants, local constants, static class constants and enumerators etc because of the historical usage of macros in C, but using that case in those situations seems like cargo cult programming that misses the motivation of macros having
MACRO_CASE to begin with. And it seems easier to implement a catch all rule to point that out rather than expecting to cover all possible cases with other rules. I have a hunch that if some codebases have different naming conventions for global variables and global constants, then some people are going to turn off a rule that doesn’t have enough granularity for them instead of sticking to naming conventions that are compliant with the existing granularity of the rule set.
I see your point. I’ve created a ticket CPP-3749 to record traction for a more flexible naming-conventions rule set.