Separate UI from DB-access (UI in line nnn of <filename>)

Rule "sepdbui" gives this warning when it finds statements for User-Interface and also statements for database access in the same compilation-unit.

The text of the warning contains the first line number where a User-Interface statement was encountered.

The first occurence of a database access is found on the line number listed in the "line" column of the Results window.

Statements for User-Interface include keywords such as ENABLE, DISABLE, MESSAGE, DISPLAY, APPLY or references to form widgets like buttons or fill-ins.

statement has no effect

Rule "noeffect" gives this warning when it finds a statement which does
nothing. For example, these are a valid statements, but they do nothing:

     
     1 + 1.
     hEditor:READ-ONLY.

These statements compile and run fine, but nothing happens. They probably don't do what the programmer intended to do, so they are probably errors.

Less obvious, and more likely to cause problems, is the following statement.
The programmer might have expected the EQ to do an assignment,
but in fact, EQ only does a comparison. This statement does
nothing other than an equality comparison between i and 12:

     i eq 12.

Known issue: methods without brackets:

IF function is confusing, use parentheses

Rule "ifparens" gives this warning when it finds an IF function (not
an IF statement) where ELSE is followed by an operator. This may cause
confusion, which can be solved by putting parentheses around the IF
function.

ASSIGN answer = IF x>0
                   THEN 10
                   ELSE 20 
                + 3000.
DISPLAY answer.

'answer' will be 3020 when x<=0.

ifindent2: IF statement with questionable indenting or couldn't check

This page is only a quick overview of this rule, for more details see "ifindent-details".


When you run rule "infindent2", you are actually running rule "infindent" but only for the informational warning messages.

warning messages given

• 201: informational. The next statement after the IF isn't in the same file as the IF,
  so we can't meaningfully compare indents.

• 202: informational. The next statement node after the IF has less indent than the IF.
• 203: informational. A subnode of the IF is in a different file, so no meaningful
  indent comparison can be made on this node. Only one of these warnings are
  output per IF statement, as an indicator.

How to suppress these warnings:

ifindent1: IF statement with indenting that could indicate a bug

This page is only a quick overview of this rule, for more details see "ifindent-details".


When you run rule "infindent1", you are actually running rule "infindent" but without the informational warning messages.

Rule "ifindent1" gives this warning when it finds an IF statement with confusing indentation.

  IF ready THEN              
     ASSIGN 
        a = x
        b = y.
        c = z.                  

It looks like the second statement ( "c = z." ) will only be executed when the IF-condition is true.

the risc:

ifindent1: IF statement with indenting that could indicate a bug

ifindent2: IF statement with questionable indenting or couldn't check

These two rules share the same code base, but the warnings are separated into
major warnings (from ifindent1) and
minor warnings (from ifindent2).
This allows the more important warnings to have a higher severity.

If you want to run both rules "ifindent1" and "ifindent2", you might as well run rule ifindent instead to double the performance.

The rules output a variety of warnings for different situations. The major,
or 100-level, warnings will generally indicate either possible bugs or bad
indenting, and the minor, or 200-level, warnings generally do not indicate
bugs, but rather are IF statements which for various reasons cannot be checked
for potential bugs.

how these rules work

ifindent: IF statement with inconsistent indenting

This page is only a quick overview of this rule, for more details see "ifindent-details".

Rule "ifindent" will by default not run, because it is not listed in file prolint/rules/rules.d.
Instead, the rules ifindent1 and
ifindent2 are listed by default, these two rules include the entire source of "ifindent".

If you plan to use both "ifindent1" and "ifindent2", you may consider to use "ifindent" instead because it will perform better.

proc [procname] not found on server [handle]

Rule "runasnotfound" gives this warning when it finds a RUN statement
for an external procedure on an Appserver, while this external procedure can not be
found. It tries to prevent Progress run-time error 293.


The rule can only work if the source for the appserver partition is
available in the Propath of the Prolint session.
.

/* Prolint will check for runs in appserver context: */
RUN subdir/filename.p ON hAppServer.

/* Prolint will NOT check if subdir/filename.p exists: */
RUN subdir/filename.p.

See also rule runnotfound to check for
"RUN" statements that don't have the "ON [SERVER]" option.

the risc:

proc [procname] not found

Rule "runnotfound" gives this warning when it finds a RUN statement
for an external procedure, while the external procedure can not be
found. It tries to prevent Progress run-time error 293.
.

/* Prolint will check if subdir/filename.p exists: */
RUN subdir/filename.p.

/* Prolint will NOT check for runs in appserver context: */
RUN subdir/filename.p ON hAppServer.

See also rule runasnotfound to check for
"RUN ... ON SERVER ..." statements.

the risc:

FIND|CAN-FIND FIRST|PREV|LAST|NEXT buffer

Rule "allfinds" gives this warning for every FIND or CAN-FIND that has a FIRST|PREV|NEXT|LAST qualifier. This is to warn for compatibility with Oracle dataservers: Oracle has some issues with find first, PSC recommends they get converted to
something like "for first" or "open query".

MESSAGE not an Alert Box

Rule "alertmessage" gives this warning when it finds a MESSAGE statement without the VIEW-AS ALERT-BOX option.

the risc:

GUI looks bad when SESSION:APPL-ALERT-BOXES happens to be FALSE.

How to suppress these warnings:

You can put directive {&_proparse_ prolint-nowarn(alertmessage)} directly before the MESSAGE statement.
See also: suppress warnings.

Abbreviation of table &1 used (&2)"

Rule "abbrevtable" gives this warning when it finds an abbreviated table name.

FOR EACH custome NO-LOCK:  /* abbreviated "customer" to "custome" !! */
    DISPLAY custome.customer-name.  
END.

the risc:

The abbreviated table name may become ambiguous after you add a new table to the database. In the example, imagine someone adds table "custome" to the schema...

known issues:

This rule does not run in Progress version 8. If you run Prolint in Progress 8, this rule will simply do nothing.

The rule only looks at actual table names, not field names. For example:

FOR EACH custome NO-LOCK:  /* this will be noticed */
    DISPLAY custome.customer-name.  /* but this will not be noticed!! */
END.

how to solve this:

Abbreviated [keyword] for [keyword]

Rule "abbrevkwd" gives this warning when it finds an abbreviated keyword in the source code.

Examples:

- Abbreviated MOVE-AFTER for MOVE-AFTER-TAB-ITEM

- Abbreviated SUBST for SUBSTITUTE.

the risc:

Confusion: is SUBST() actually the SUBSTRING() function or the SUBSTITUTE() function? Also, the source may compile differently in a next Progress version if the abbreviation becomes ambiguous.

how to solve this:

Don't abbreviate, just type the extra keystrokes.

How to suppress these warnings:

-

PRO4m is a commercial product that creates HTML reports about your projects, looks for unused database objects, and more.
You can find information about PRO4m at www.progress-plus.com.

PRO4m can call Prolint to incorporate the results from Prolint in its HTML reports. If you want to give it a try download "3PRO" from www.progress-plus.com.


3PRO combines PRO4m, Proparse and Prolint in a single setup for your convenience.