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!
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
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
widget X created but never deleted
memory in memptr X is never released with set-size(X)=0
type mismatch in parameter X when calling user-defined function Y
insufficient index information specified in WHERE-clause
abbreviation of database field names is not allowed
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.
Has to be customizable: some want only lowercase, others want only uppercase keywords.
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. Will probably need two rules for this: one for internal procedures and a second, much more complicated rule for external procedures
enforce that each program (compilation unit) starts with a particular boilerplate comment
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