Why is cppcheck, valgrind, vera++, rats, pc-lint, ... not all the same? about sonar-cxx HOT 9 CLOSED

Cxxexternal was brought later in the game to cope with the fact the number of sensors were increasing substantially. The existing sensors exist because there was no decision made to use the external instead of the own sensor. And because they have a substantial user base? At least some like cppcheck

from sonar-cxx.

Found this https://pypi.python.org/pypi/sonar-rules-extractor.
But had no time yet to check it.

from sonar-cxx.

This looks to be implementation specific? Maybe it can refered in the wiki that such tool exists for supported static analysers. The output format is at least compatible with the external sensor.
One thing we need to take care is that the inclusion of rules in the extensions/rules will be dropped it in the future and the web interface will be used instead, hope this is not going to be a limitation when several external definitions are in place

from sonar-cxx.

This topic ('builtin' vs. 'external' rules) has somewhat more depth.

Some rules / checks (repositories 'Sonar' and 'Sonar common') are implemented completely inside the plugin and are builtin 'by definition'. But they're not subject of this discussion.

There are also other checks, which are not implemented in the plugin but should be better 'built-in', because:

1. Builtin rules are easier to setup and use. Just install the plugin and feed a report.
2. We can reach and maintain better quality of the rules if we have them in the same source code repository and ship them with the plugin. Note: it's not trivial and generally takes time and manual care to get it right, because:

• Extracted name and description have often to be manually edited to be actually readable, understandable, consistent, etc. Look at "cppcheck --errorlist" if you want to see examples.
• The mapping of 'native' categories/severities to Sonar ones cannot be automated most of the time. And it gets even more laborious with the introduction of the SQALE model.
• In most cases you want to support a range of versions of the used checker, which raises additional issues.

Of course, those checks (and according checkers) should be worth the effort, i.e. be freely accessible, relevant, used widely, have a low false positives rate etc. Cppcheck and his checks certainly fall in this category (although the quality seems to decline nowadays).

Checks from vera++ and RATS are IMO not really worth it and could be handled as 'externals'. They have dedicated sensors because of historical reasons. If I understand Bertk correctly, vera++ could be replaced soon by checks from repository 'Sonar'.

Although PC-Lint is (according to my ranking) less relevant than Cppcheck and could be an external, it:

• has its users
• is also older than the cxxexternal-thing
• has special logic in its sensor (Misra rules remapping).

Valgrind is a dynamic checker. We need a dedicated sensor because of the reports being structured differently.

But in the future, people integrating further checkers should use the cxxexternals-feature with priority. The entrance barrier into the builtin-area should be high.

from sonar-cxx.

Rats might be a be different as the focus is on security. So I would keep
that one, vera would be nice to be replaced already for the next release.

If you are bringing more tools, I would consider for the future llvm tools.
And this clang modernizer would be a great addition
On Dec 30, 2013 9:17 PM, "Waleri Enns" [email protected] wrote:

This topic ('builtin' vs. 'external' rules) has somewhat more depth.

Some rules / checks (repositories 'Sonar' and 'Sonar common') are
implemented completely inside the plugin and are builtin 'by definition'.
But they're not subject of this discussion.

There are also other checks, which are not implemented in the plugin but
should be better 'built-in', because:

1. Builtin rules are easier to setup and use. Just install the plugin and
   feed a report.
2. We can reach and maintain better quality of the rules if we have them
   in the same source code repository and ship them with the plugin. Note:
   it's not trivial and generally takes time and manual care to get it right,
   because:

• Extracted name and description have often to be manually edited to
  be actually readable, understandable, consistent, etc. Look at "cppcheck
  --errorlist" if you want to see examples.
• The mapping of 'native' categories/severities to Sonar ones cannot
  be automated most of the time. And it gets even more laborious with the
  introduction of the SQALE model.
• In most cases you want to support a range of versions of the used
  checker, which raises additional issues.

Of course, those checks (and according checkers) should be worth the
effort, i.e. be freely accessible, relevant, used widely, have a low false
positives rate etc. Cupcake and his checks certainly fall in this category
(although the quality seems to decline nowadays).

Checks from vera++ and RATS are IMO not really worth it and could be
handled as 'externals'. They have dedicated sensors because of historical
reasons. If I understand Bertk correctly, vera++ could be replaced soon by
checks from repository 'Sonar'.

Although PC-Lint is (according to my ranking) less relevant than Cppcheck
and could be an external, it:

• has its users
• is also older than the cxxexternal-thing
• has special logic in its sensor (Misra rules remapping).

Valgrind is a dynamic checker. We need a dedicated sensor because of the
reports being structured differently.

But in the future, people integrating further checkers should use the
cxxexternals-feature with priority. The entrance barrier into the
builtin-area should be high.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/97#issuecomment-31362629
.

from sonar-cxx.

Hi, I closed the issue exitendly, sorry for this.

Can you please give me some hints which Vera++ rules should be migrated to CXX. I feel most of them are outdated and we use VS IDE with CodeMaid which supports some code formating.

• obsolete_______ F001_(CR) detected in isolation
• obsolete_______ F002_File names should be well formed
• obsolete_______ L001_Avoid trailing whitespace
• check available L002_Don't use tab characters
• obsolete_______ L003_No leading and no trailing empty lines
• check available L004_Line too long
• obsolete_______ L005_Too many consecutive empty lines
• check available L006_Source file is too long
• ???____________ T001_One-line comments should not have forced continuation
• ???____________ T002_Reserved name used for macro
• obsolete_______ T003_Keyword not followed by a single space
• obsolete_______ T004_Keyword not immediately followed by a colon
• obsolete_______ T005_Keyword not immediately followed by a semicolon
• obsolete_______ T006_Keyword not immediately followed by a semicolon or a single space
• obsolete_______ T007_Semicolon is isolated from other tokens
• obsolete_______ T008_Keyword not followed by a single space
• obsolete_______ T009_Wrong spacing around comma
• obsolete_______ T010_Identifiers should not be composed of only 'l' and 'O'
• obsolete_______ T011_Opening/closing curly bracket mistake
• ???____________ T012_Negation operator used in its short form
• check available T013_No copyright notice found
• ???____________ T014_No reference to the Boost Software License found
• ???____________ T015_Incorrect HTML links
• obsolete_______ T016_Min/max potential macro substitution problem
• ???____________ T017_Unnamed namespace not allowed in header file
• ????___________ T018_Using namespace not allowed in header file
• check available T019_Full block {} expected in the control structure

from sonar-cxx.

we now use clang formater for this, however sometimes devs forget to format
the code. So i still useful to include minor formatting rules to keep devs
using the formatter. These are the rules we don't use from vera.

And these are the ones, we have:

I think the blockers, majors and critical are worth porting. Others imo can
be removed.

On Wed, Jan 1, 2014 at 3:42 PM, Bert [email protected] wrote:

Reopened #97 #97.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/97
.

from sonar-cxx.

OK, then only 3 rules are in scope. T017, T018 should be available end of the week. T002 might be implemented later because I do not want to duplicate the keywords but should not be a problem.
T002_Reserved name used for macro
T017_Unnamed namespace not allowed in header file
T018_Using namespace not allowed in header file

from sonar-cxx.

seems to be finished, closing

from sonar-cxx.