Using Sonar for C++ naming conventions

Template for a good new topic, formatted with Markdown:

  • ALM used (GitHub, Bitbucket Cloud, Azure DevOps)
  • CI system used (Bitbucket Cloud, Azure DevOps, Travis CI, Circle CI
  • Scanner command used when applicable (private details masked)
  • Languages of the repository
  • Only if the SonarCloud project is public, the URL
    • And if you need help with pull request decoration, then the URL to the PR too
  • Error observed (wrap logs/code around with triple quotes ``` for proper formatting)
  • Steps to reproduce
  • Potential workaround

Hello,

We are using SonarCloud to analyse C++ code baseline. I’m looking for a solution if sonar ecosystem provides naming convention checking for C++. I’m particularly interested in how we can enable sonar for both CLI and for IDEs to verify correct naming conventions for variables, classes and structs are applied. Do you have any recommendation?

Do not share screenshots of logs – share the text itself (bonus points for being well-formatted)!

Hello, @dbeker, and welcome to the community,

There are rules for naming conventions, although they are disabled by default.
For instance, S100 for functions, and there are others.

In SonarCloud, you must create a new Quality Profile for your organization (if you do not have one already).

  1. Go to your organization page (https://sonarcloud.io/organizations/...)
  2. Click on “Quality Profiles”
  3. Search for C++; there should be two built-in. You can pick any of the two as a base profile (I would advise Sonar Way by default).
  4. Click the three dots to the right and then “Extend.”
  5. Give it a new name
  6. Click on “Inactive rules.”
  7. Search for, say, S100, click on “Activate,” and provide a regex used to verify the naming convention

Once this is done, you can either set this new profile as the organization’s default or go to the affected projects and apply the new profile.

SonarLint will pick these changes if you use connected mode.

Please let me know if this helps.

Also, the changes take effect on new analyses, so you will not immediately see any issue raised in SC after activating the rules.

Thank you Alejandro.

Following it up, would it be possible to extend those naming conventions? For example, would it be possible to separate private and public member variables? How can we define our own custom rule set for naming conventions if it doesn’t exist in the second link you shared?

Defining your own CFamily rules is not possible, but you can import reports generated by other tools, so you could conceivably roll out something based on clang’s json dump of the AST (which is not necessarily stable between releases, though).

What rules do you have in mind, apart of differentiating between public/protected/private member variables?

Hi Alejandro,

Thank you for your response. We need the same rules that you can enforce with clang-tidy. You can find the rules at https://clang.llvm.org/extra/clang-tidy/checks/readability/identifier-naming.html.

Is there any possibility that this will be included in your roadmap soon?

Thanks for your assistance!

Hi @aalvarez.

Do you have any updates regarding the naming conventions?

Many thanks!

Hello @claudg2_mdt ,

Unfortunately, there is nothing on the roadmap in this respect. I have forwarded this thread to our PM, though, so we note the interest in a feature like this.

Hi @claudg2_mdt ,

Thanks for reaching out.
I can see the clang-tidy check is indeed more refined and configurable than what we offer.
Please, would you be able to elaborate on what you need specifically that is not covered by the rules that @aalvarez mentioned?

Thank you very much