A rule is a specific statement that describes one action to follow when you write code. For example, the following statements are code review rules:
- Avoid conditional expressions with more than four operators
- Avoid nesting more than one class
- Avoid nesting more than one if statement
Rules form the basis of an analysis configuration. When you perform an analysis, you check whether your resources comply with a specific rule, or set of rules. You can modify rules and create user-defined rules if you need them to be more specific to your application design standards. The rules listed earlier, for example, belong to the design principles category. Rules that apply to similar capabilities, or code structures, belong to the same category. You can apply rules from several categories depending on the purpose of your review.
Severity levels
Rule authors assign a severity level to each rule to specify how seriously a resource that conflicts with the rule deviates from the standards. Each rule has one of the severity levels in the following table:
| Icon | Severity level | Description |
|---|---|---|
 |
Recommendation | This is the lowest severity level. The result indicates a problem that is not serious, but that you should consider fixing soon. |
 |
Warning | This severity level indicates that a resource very likely has a problem that you need to resolve. |
 |
Severe | This is the highest severity level. It indicates that you should resolve the problem that the result points to. |
Although recommendation is the lowest level, it is still important to address results with this severity level. Even if these results are not immediate problems, they could lead to problems in the future. The rules are based on a set of best practices and industry standards to which development teams should adhere.
Rule categories
Analysis providers are components of the analysis framework that implement groups of tools that contain categories. You can select different providers for different types of analysis and, depending on the requirements of your analysis, you can enable or disable a rule category and individual rules in the category.
An example of a rule category is the performance category for code reviews. Performance, as an important aspect of the overall quality of an application, should be one of the characteristics you test in a code review. The performance rule category has three subcategories, memory, profiling, and speed, each of which contains a set of rules that you apply to your source code when you run an analysis with this category selected.