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.

Avoid the usage of a shortcut to access globals. Some of the reasons are:

  • The developer must be aware of the context under which shortcut is being used.
  • Avoid ambiguity in the global access.
  • Obtain more clarity in code.

Noncompliant Code Example

In the code snippets below, it is supposed that the context of globals of the second snippet is that of the first snippet.

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.

In these code samples:

    do ..someMethod(.x)
    // or
    do ##class(some.Class).someMethod(.x)

x is automatically created and initialized.

However, this can be confusing since no prior declaration of x exists.

For clarity reasons, it is recommended that a prior declaration exists. The preferred way here is to use #dim which, even though it will do nothing to create the variable itself, has the advantage that you can declare the type, if any. Therefore, the code above would become:

Consider this code:

    Class Fubar
    {
    ClassMethod m(someArg as Some.Class)
    {
        if (someArg =' "") {
            w "my argument was a null oref", !
        }
    }
    }

There is a trap in this code.

ObjectScript allows spaces between the unary negation operator (that is, ') and its argument: 'a and ' a are the same.

Which means that another way to write the code above would be:

Pages