# Built-in rule tags

Most rules have some tags out of the box. Issues inherit the tags of the rules that raised them. Sonar provides a list of built-in tags and custom tags can be used. The Quality Standards administrator can add tags to rules and end-users can manage the tags assigned to their project's issues.

Here is a non-comprehensive list of what some of those built-in tags mean:

* `architecture`: there is something questionable about the architecture of the code.
* `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](https://wiki.sei.cmu.edu/confluence/display/seccode/SEI+CERT+Coding+Standards) standard. There are currently three CERT standards: [C](https://wiki.sei.cmu.edu/confluence/display/c/SEI+CERT+C+Coding+Standard), [C++](https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=88046682), and [Java](https://wiki.sei.cmu.edu/confluence/display/java/SEI+CERT+Oracle+Coding+Standard+for+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…
* `cwe`: relates to a rule in the [Common Weakness Enumeration](http://cwe.mitre.org/). For more on CWE and on security-related rules in general, see the [security-related-rules](https://docs.sonarsource.com/sonarqube-cloud/standards/managing-rules/security-related-rules "mention") page.
* `lock-in`: environment-specific features are used
* `misra`: relates to a rule in one of the [MISRA](http://www.misra.org.uk/) standards. While the MISRA rules are primarily about C and C++, many of them are not language-specific (E.G. don’t use a float as a loop counter) but are simply good programming practices. That’s why you’ll see these tags on non-C/C++ rules. MISRA and MISRA C are the registered trade marks of [The MISRA Consortium Limited](https://misra.org.uk/).
* `pitfall`: nothing is wrong yet, but something could go wrong in the future; a trap has been set for the next guy and he’ll probably fall into it and screw up the code.
* `suspicious`: it’s not guaranteed that this is a **bug**, but it looks suspiciously like one. At the very least, the code should be re-examined & likely refactored for clarity.
* `unpredictable`: the code may work fine under current conditions, but may fail erratically if conditions change.
* `unused`: unused code, E.G. 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.

## Related pages

* [rules](https://docs.sonarsource.com/sonarqube-cloud/standards/managing-rules/rules "mention")
* [adding-tags-to-rule](https://docs.sonarsource.com/sonarqube-cloud/standards/managing-rules/adding-tags-to-rule "mention")
* [#tagging](https://docs.sonarsource.com/sonarqube-cloud/managing-your-projects/issues/editing#tagging "mention")