Automated static analysis tools. The analysis of source code without executing the code itself.
Category
Rules that check for defects that affect the behavior of the program.
Errors pertaining to the validation of data, whether that is external (user input) or internal (result values). Most often the absence of a check for return values or user input when such a check might prevent errors.
Rules that check violations regarding concurrency issues.
Rules that check that errors and exceptions are properly handled.
Errors concerning interactions with different parts of the system. This can be:
• Interacting with external entities such as libraries, hardware, or the oper- ating system.
• Interacting with internal parts of the systems via, for instance, function calls with the wrong parameters or calling the wrong function.
• How a class exposes itself via its public interface.
• Errors made during inheritance, such as errors made when overriding
methods.
Errors pertaining to program logic. Primarily concerned with comparisons, control flow, and algorithms.
Rules that check violations regarding the migration of one version of the pro- gramming language to another.
Errors concerning the initialization, casting, or release of data, whether that data is external (databases) or internal (variables).
Rules that check for problems that only affect the future development efforts of changing or adding to the system, but have no impact on the correctness of the program.
Rules that check the code for violations regarding coding conventions that affect the compiled output of the code.
Rules that check the structure, in terms of the file system or the coupling, for violations of common conventions.
Rules that check the documentation for violations of common conventions.
A rule that measures a certain attribute of the code. The rule might only be to inform the developer of the value of the attribute, or it can give warnings/errors based on certain thresholds.
Rules that check violations of common naming conventions.
Rules that check for violations of proper object oriented design principles.
Rules that determine if a specific piece of code could be simplified to improve readability and understandability.
Rules that determine if a piece of code or artifact is redundant and can be safely deleted.
Rules that check the code for violations of style conventions, that do not affect the compiled output of the code.
Rules that identify neither functional nor maintainability defects.
Rules that rely on user defined regular expressions. Because the user can use them to check a multitude of things, it is not possible to categorize these rules in general.
Rules that configure how the tool works, rather than which defects it checks for (or does not check for). Examples of such rules might be: whether to colorize the output, how to write the results to file, or how much memory the tool can use.