Built-in rule tags
SonarQube users can add tags to rules and issues and most rules have some built-in tags out of the box.
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.
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.
OWASP: relates to a rule in the OWASP Top 10 2017 security standard. Note, that the OWASP Top 10 is a list of high-level security risks which translates to many, many potential rules. "owasp-ax" tags should no longer be used, they should be considered as "deprecated" because they map to old "OWASP Top 10 2017". The "Security Category" facet should be used instead to filter on recent OWASP Top 10s (2021+).
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.
sans-top25: This tag is based on outdated statistics and should no longer be used. Instead, it’s recommended to rely on the "CWE Top 25" reports, which are available in Enterprise Edition.
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.
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.
Last updated
Was this helpful?