This rule reports any method or class method whose number of statements is above a certain threshold (50 by default; it is configurable).

The more statements a method has, the harder it is to read, test and modify. Consider splitting this method into smaller methods.

This rule checks for the nesting depth of methods.

Methods which are too deeply nested are usually an indication that one, or several, of the below problems apply:

• the method tries to do too many things;
• objects used by this method lack isolation;
• the code in the method fails to account for early exit conditions.

The first of those conditions above is the most frequent one; the suggested fix is therefore to split the logic of this particular method into several methods.

This rule reports any method or class method whose complexity is above a certain threshold (20 by default; it is configurable).

The more complex a method is, the harder it is to read, test and modify. This is a strong indication that the code should be refactored.

This check detects the number of local variables declared/used in a method and reports an issue if this number is deemed to be too high (this number is configurable).

Moreover, it is often the case that a method with too many variables is also too complex. It is therefore strongly recommended to refactor the code in order to avoid this issue.

A method with too many arguments is hard to read and maintain.

Moreover, it is often the case that a method with too many arguments is also too complex. It is therefore strongly recommended to refactor the code in order to avoid this issue.

If a property of type %String (or %Library.String) is declared without a MAXLEN parameter, then the default length (of 50) will be used when an instance of the class is persisted.

Depending on the situation, this will lead to either wasted storage (if 50 is too high) or writes and retrievals which do not perform as well as they could (if 50 is too low).

If possible, modify the declaration of this property and add this class parameter, such as, for instance:

    Property smallString As %String(MAXLEN = 10);

This inspection reports all variables declared in the context of a method or classmethod, which is not used afterwards anywhere in this method.

Such variables take unnecessary memory and processing power; they should be removed for efficiency reasons.

Execution of SQL statements in ObjectScript can be done in one of two ways:

• using the &sql(...) statement;
• using the newer SQL classes, such as %SQL.Statement.

The problem with using &sql(...) is that the execution plan will be calculated the first time the query is executed, and never be re-evaluated again.

Unused method arguments waste computer resources, and the waste is all the greater that the method is called more often.

Either suppress this method argument, or refactor the code to avoid this issue.