# 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%20). 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.
* **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.
* **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.

## Related pages

* [adding-tags-to-rule](https://docs.sonarsource.com/sonarqube-community-build/quality-standards-administration/managing-quality-profiles/adding-tags-to-rule "mention")
* [#tagging](https://docs.sonarsource.com/sonarqube-community-build/user-guide/issues/managing#tagging "mention")