# 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.
* **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 [Security-related rules](/sonarqube-server/2026.2/quality-standards-administration/managing-rules/security-related-rules.md).
* **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 a rule](/sonarqube-server/2026.2/quality-standards-administration/managing-rules/adding-tags-to-rule.md)
* [Editing issues](/sonarqube-server/2026.2/user-guide/issues/managing.md#tagging)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.sonarsource.com/sonarqube-server/2026.2/quality-standards-administration/managing-rules/built-in-rule-tags.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.