Comments (9)
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:
- Builtin rules are easier to setup and use. Just install the plugin and feed a report.
- 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:
- Builtin rules are easier to setup and use. Just install the plugin and
feed a report.- 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:
—
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.
Related Issues (20)
- Verify deprecated Web API endpoints and parameters HOT 1
- Optimizing the execution of sensors
- C++ plugin causing an issue while running Java/python projects HOT 5
- How to define program language HOT 1
- cxx-custom-checks-example-plugin can not to report issue information HOT 8
- The SonarScanners download only required 3rd-party plugins HOT 1
- [Fix][cxx-custom-checks-example-plugin] the problem that sample rules could not be loaded and registerd normally HOT 1
- BREAKING CHANGE: Rename 'sonarQubeMinVersion' to 'pluginApiMinVersion'
- The property 'sonar.login' is deprecated
- False positive with cppcheck:passedByValue and std::move in constructor HOT 3
- Squid preprocessor error and the sonar scanner procedure will be stuck HOT 9
- Cppcheck 2.14.0 support HOT 3
- Cognitive complexity metric does not understand newer C++ syntax HOT 9
- Not getting sonar report while using sonar-cxx for SonarQube 9.9.5 LTS HOT 7
- NoClassDefError with the SonarScanner HOT 7
- Unable to run sonar-scanner with cppdepend HOT 1
- Preprocessor allows for name collision with directory like 'exception' HOT 1
- Sonar exclusion is not working for C application HOT 2
- sonar-cxx with SonarQube 10.5 community version HOT 1
- sonar.cxx.jsonCompilationDatabase not working HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sonar-cxx.