10.4 | User guide | Rules | Built-in rule tags
Built-in rule tags
Tags are a way to categorize rules and issues. Issues inherit the tags on the rules that raised them. Some tags are language-specific, but many more appear across languages. Users can add tags to rules and issues and most rules have some tags out of the box. Here is a non-comprehensive list of what some of those built-in tags mean:
- brain-overload: there is too much to keep in your head at one time.
- bad-practice: the code likely works as designed, but the way it was designed is widely recognized as being a bad idea.
- CERT: relates to a rule in a CERT standard. There are currently three CERT standards: C, C++, and Java. Many of these rules are not language-specific, but are good programming practices. That's why you'll see this tag on non-C/C++, Java rules.
- clumsy: extra steps are used to accomplish something that could be done more clearly and concisely. (E.G. calling .toString() on a String).
- confusing: will take maintainers longer to understand than is really justified by what the code actually does.
- convention: coding convention, typically formatting, naming, whitespace, etc.
- CWE: relates to a rule in the Common Weakness Enumeration. For more on CWE and on security-related rules in general, see Security-related rules.
- design: there is something questionable about the design of the code.
- lock-in: environment-specific features are used.
- pitfall: nothing is wrong yet, but something could go wrong in the future; a trap has been set for the next person, and they'll probably fall into it and screw up the code.
- suspicious: it's not guaranteed that this is a bug, but it suspiciously looks like a bug. At the very least, the code should be re-examined and likely refactored for clarity.
Rule severity and changing rule severities are deprecated. See the Code analysis based on Clean Code page for an explanation of Sonar’s code analysis and the impact issues have on your code.
- unpredictable: the code may work fine under current conditions, but may fail erratically if conditions change.
- unused: unused code; for example, a private variable that is never used.
- user-experience: there's nothing technically wrong with your code, but it may make some or all of your users hate you.
Was this page helpful?