David,
Of course you're justified in doing it this way - it's your code, and it
certainly doesn't appear to be unreadable (even though I assume this is a
made-up example). As can be seen from the responses to this thread, no
matter *how* you write code, someone else won't like it :)
However, a question does come to mind: Was the main point of doing this to
be able to use local variables in subprocedures, or did you split the code
up this way simply to make it more readable?
If you're not using local variables in the subprocedures, you are probably
just as well off using (gasp!) subroutines, since each subroutine can
include the return statement:
/FREE
exsr doThis;
exsr doThat;
return;
begsr doThis;
//code goes here
if condition;
return;
endif;
endsr;
begsr doThat;
//code goes here
if condition;
return;
endif;
endsr;
/END-FREE
Just as simple to read (for you), the code is still broken up into separate
chunks (which can't as easily be tested separately, I'll admit) and each
subroutine can RETURN individually. Your progarmmmer friend will like it
because it's all in one main procedure.
I'm not trying to restart the "subroutines vs. subprocedures" flame war, but
*if* you're using subprocedures simply as a way to break up the code
*and*you're not making a lot of use of local variables in those
subprocedures,
then it seems like a lot of unnecessary overhead and hassle to create all
the P-spec lines, interfaces and whatnot. I've seen several cases where
programmers (good ones, too!) are so concerned about *never* using global
variables that, they will contort the code into a series of overly complex
subprocedures, where a simple main line with some global variables and a few
subroutines would do the job equally well.
The people who talk about the wonderful testability of using individual
procedures generally fail to point out that they *don't* test their
procedures separately, unless those procedures are in service programs.
In-line subprocedures (i.e. ones coded in the module source member) are
often simply subroutines in disguise (possibly with their own variables) and
are almost never tested individually...
Well-written code should follow certain rules of readability, but frankly,
the "never use global variables" rule is one I often disagree with.
I use lots of service programs, lots of in-line subprocedures, lots of
subroutines, lots of global variables, and I rarely bitch about other
people's code. Mind you, no-one's ever complained to my face about my code
either, even though I assume some people don't like it... :)
Rory
On Mon, Mar 1, 2010 at 2:44 AM, David FOXWELL <David.FOXWELL@xxxxxxxxx>wrote:
Hi,
I tend to divide my code into subprocedures in a program just to improve
readability, even when there is very little risk of that subprocedure being
called from anywhere else. Each subprocedure will correspond to a specific
task executed by the program.
Eg,
/FREE
IF not doThis ( )
RETURN
ENDIF;
IF NOT DoThat ( )
RETURN
ENDIF;
/END-FREE
In these cases I will use global variables unless not possible. That leaves
me with a load of one line prototype declarations in my code :
D doThis PR
D doThat PR
I've just discovered that this style seems to annoy at least one programmer
who prefers to see all the code in one main procedure and does not like to
see all those PR's PI's and returns, etc. Rather embarassing.
Am I justified in coding in this way or am I wrongly using subprocedures?
midrange.com
