×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
IF not doThis ( )
RETURN
ENDIF;
IF NOT DoThat ( )
RETURN
ENDIF;
So you know, it is generally considered bad form to issue RETURN before the
ends of the procedures/functions in which they appear. Put another way,
Return should appear only as the last statement of a procedure. If it is
later determined that this procedure musty return a variable, how many
(otherwise unrelated) changes will need to be made in order to support that?
It is also considered bad form to use the word NOT where avoidable. How
much clearer would your code appear if it said:
IF doThis ;
If doThat ;
doStuff() ;
EndIF ;
EndIF ;
Return ;
Am I justified in coding in this way or am I wrongly using
subprocedures?
Your goal is worthy; your reasons for that goal may need support.
The primary reason I have found for procedures (other than reuse) is
testability. I can put a procedure together, test it, ensure that it's
solid and know that it will continue working in spite of the fact that it's
part of a multi-thousand line program. It has its own work variables, it
won't interfere with the main (or other) procedures... it's truly isolated
and therefore less susceptible to introduction of bugs due to changes
elsewhere.
Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
They may forget what you said, but they will never forget how you made them
feel.
-- Carl W. Buechner
midrange.com
