my 2 coppers worth on this subject:
even when using only global variables in subprocs...use the subproc
instead of subroutines. why? simply because you don't *need* local
variables at this point during the life of the program you may *need* to
add them. if it's already a subproc then it's alot easier than having to
convert the subroutine into a subproc (where it should have been to start
with in my opinion).
as far as the IF NOT vs. IF i have a simple rule of thumb i use (there may
be some exceptions depending on the logic needed).
the rule of thumb is this:
put the condition that you expect to occur most often as the condition.
say you have a file you are checking for a record's existence and you
expect that the record will not exist in most cases and you simply want to
bypass additional processing i would use
SETLL (mykey) myfile;
If NOT %Equal;
// skip it (iter, leave or whatever
endif;
likewise if you expect the opposite to be true then
SETLL (mykey) myfile;
If %Equal;
// skip it
EndIf;
in a nutshell, if there is a condition where you are "short-circuiting"
the logic, use the condition that does the "skip it" logic then the
additional processing only when needed. hopefully that's clear my ability
to communicate today is not very good...i hate sinus infections ugh...
Thanks,
Tommy Holden
From: Rory Hewitt <rory.hewitt@xxxxxxxxx>
To: "RPG programming on the IBM i / System i" <rpg400-l@xxxxxxxxxxxx>
Date: 03/01/2010 11:58 AM
Subject: Re: More on RPG style
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
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
