RE: More on RPG style

There have been some comments about not issuing (or avoiding - to avoid
using the word "not") separate returns. In the case where I feel I
need to drop out of the procedure immediately instead of allowing logic
flowing to the end of the procedure, I'll typically create a "EndProc"
subroutine where I'll issue the Return and do any other end-of-
procedure type stuff I need done.

If you research Cyclomatic complexity, you'll see where I'm coming from.
Programs with a higher complexity by this measurement tend also to have
higher number of defects. Multiple "exits" (as they are called here) add to
the complexity.

This usage however, would fall under the to-be-rethought category. There is
no way for a maintainer to look at the code and determine that a RETURN
precedes some bit of code that (s)he is about to add. This is a major,
hand-written invitation for additional maintenance.

I am less concerned about the NOT thing, and find many instances where I do
put the NOT test at the top because it makes more sense. But if there is an
ELSE, it is easier (for me) to understand the whole story if the NOT is NOT
at the top. ;)

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"Where a calculator on the ENIAC is equpped with 18,000 vaccuum tubes and
weighs 30 tons, computers in the future may have only 1,000 vaccuum tubes
and perhaps weigh 1 1/2 tons."
-- Popular Mechanics, March 1949