Prolint

Prolint is a tool for automated source code review of Progress 4GL code. It reads one or more sourcefiles and examines it for bad programming practice
When you are interested Prolint, you are encouraged to subscribe to this group where you find the on-line tools to collaborate and discuss Prolint. There is a discussion forum, you can submit issues (for bugs and enhancement requests), you can modify the on-line documentation. So subscribe, and then don't forget to go to your subscription details to enable the e-mail notification!


Subversion (source control)

The source code for Prolint is managed in a Subversion repository, here at the OpenEdge Hive.
You can also find a Subversion repository at Sourceforge.net, but that one is outdated.

View the repository in your web browser:
http://websvn.oehive.org/listing.php?repname=prolint

or if you prefer to use a subversion client (like svn.exe or TortoiseSvn) then you can export the trunk from svn://oehive.org/prolint/trunk/prolint


Prolint Discussion Forum

Visit the Prolint discussion forum

(but if you have an idea for a new rule, please use the Issue Tracker and use the combo-boxes to specify "component=rule" and "category=feature request")

When you are not subsrcribed to the Prolint group, you will not be able to post anything in the Forum.
Subscribing only takes a second or less, and you can unsibscribe whenever you want.


input blocking statement during database transaction

input blocking statement during database transaction


widget X created but never deleted

widget X created but never deleted


memory in memptr X is never released with set-size(X)=0

memory in memptr X is never released with set-size(X)=0


type mismatch in parameter X when calling user-defined function

type mismatch in parameter X when calling user-defined function Y


insufficient index information specified in WHERE-clause

insufficient index information specified in WHERE-clause


abbreviation of database field names is not allowed

abbreviation of database field names is not allowed


enforce the order of keywords

enforce the order of keywords. For example "FOR EACH tablename NO-LOCK WHERE ": NO-LOCK should appear immediately after tablename, not after the WHERE-clause.


check for capitalizing of keywords

Has to be customizable: some want only lowercase, others want only uppercase keywords.


no DEFINE statements between executable statements

DEFINE VARIABLE statements should not be used after any executable statements. In other words, enforce that DEFINEs only appear in the definition section before any actual logic.


check for matching parameters in RUN statements

check for matching parameters in RUN statements. Will probably need two rules for this: one for internal procedures and a second, much more complicated rule for external procedures


enforce header comment

enforce that each program (compilation unit) starts with a particular boilerplate comment


enforce that certain includefiles are used

enforce that certain includefiles are used. This rule would have to be highly customizable. The idea is: a company rule asserts that a particular includefile is included in compilation unit. Which compilation units? Which includefile(s)?


check if each opened stream is closed

check if each opened stream is closed


#
Syndicate content