ObjectScript allows to write methods which return a value but do not declare it, as in:

    Method m()
        return 1

While it is possible, it is not recommended; methods should always declare their return type, as in:

    Method m() As %Integer
        return 1

This rule detects when a method argument is reassigned in the method body but is not passed by reference.

Two possibilities exist:

This is done on purpose

While this is a distinct possibility, it is generally considered to be bad practice. It is advised that a dedicated variable be created for this purpose.

For instance, instead of doing:

    Method m(arg as %String) as %String
        // modify arg, then...
        return arg


When you use OPEN and do not specify a timeout, as in:

    // Open a file read only
    open "myfile":("R")

then the process will block indefinitely until the resource is available.

For instance, in the example above, if myfile does not exist, the process will hang.

ObjectScript allows to add default value to method arguments, and it does not require that such default values be at the end.

It is therefore legal to define a method as:

    Method m(x as %Integer = 1, y)
        // code of method here

However, this is rather confusing and should preferrably be avoided.

This rule checks that all parameters of a given method or class method have a type declared.

ObjectScript makes it possible to have typeless arguments, as in:

    Method m(foo, bar)
        // body of the method here

This makes it difficult to know what the arguments are, even if the method is documented; what is more, it prevents the IDE (Studio or Atelier) from performing completion.

It is therefore preferable to always declare argument types, as in:

In ObjectScript, you can declare arguments to be passed by reference, using either ByRef or Output modifiers, as in:

    ClassMethod m(ByRef x as %Integer)
        // Actually modifies x for the caller
        set x = x + 1

In callers, you then pass your arguments by reference using the unary dot operator, like so:

There is a trap in the following code:

    method m()
        do ..something()

Here, the quit is actually not the quit command, but a line label.

This is probably a bug which should be fixed.

This check verifies that a legacy flow control statement has at least one associated statement to it.

The trap with legacy flow control statements is that associated statements must be on the same line; the following will actually execute ..something() even though the condition is false:

    method m()
        set condition = 0
        if condition
            do ..something() // NOT THE SAME STATEMENT!!

The correct way to write the above is actually:

It is possible for legacy flow control statements (if, else and for) to have more than one statement; for instance:

    // if condition c is true, set variable x then print variable y
    if c set x = 1 w y,!

However, this is hardly readable.

If you have more than one statement, it is preferred to use the brace forms of these statements instead; the code above becomes:

Those two constructs implicitly inspect the value of the $TEST special variable: