For some reason the cut and paste from BDT to this list, duplicated every 
single line.
Which is unfortunate.  It didn't look that way when I SENT it to the list, only 
when I received it back again.
So just ignore every other line in the code segment



-----Original Message-----
From: Tony Gravagno <[email protected]>
To: u2-users <[email protected]>
Sent: Wed, Apr 25, 2012 3:38 pm
Subject: [U2] Coding style with lists (was BDT...)


Please forgive a digression on coding style.
> From: Wjhonson 
 By the way, the point of selecting out to a list and then
eadnexting
 from that list, for those who are virgins, is that two selects in
ne
 program, are almost always prevented from stepping on each other's
 toes.
Are you talking about SELECT FV1 TO LISTX followed by SELECT FV2 TO
ISTX?
hat's the reason for the CLEARSELECT statement. 
Re-using a variable is perfectly reasonable for many reasons. Re-using
 variable because you're not sure if its state is awkward.
The word "almost" above is either an error or feigned insight. In
ither case, I don't like anything in code "almost" working.
Some code is structured such that the management of the flow is
xplicitly controlled. Some code is written to cover for situations
here it is not aware of the current state, so it attempts to
ompensate.
I prefer the former to the latter. If you're not sure of the "state"
f processing at some point in the code then you can only guess what's
appening, and you could miss options. "State management" is a
evelopment technique that precludes many kinds of errors, and unusual
r unnecessary workarounds. There are times when you legitimately may
ot know exactly what the code is doing, where the code is not aware
f its execution state, but this should not be by design.
For the above situation, you're either actively reading through a
ist, or you've made a logical choice to stop using that list. When
hat choice is made, clear the variable if you intend to re-use it -
ven if not. This way you're not re-using the same variable "just in
ase" it was already in some prior state, and if your code does happen
o fall into a different path of logic, maybe from a later mod, the
ist won't accidentally be active with IDs from another selection. If
hat doesn't fit your code logic, use a state variable that identifies
he selection currently active, and reset that variable when the list
s exhausted or when you have chosen to stop using it. Check the
ariable before using the list to ensure it's in the proper state.
This is the kind of thing that separates amateurs from pros - sorry if
t offends anyone, but it is what it is, and I prefer posting
omething like this to the technique that was offered.
Being a non-virgin doesn't mean you know how to, uh, do it.  ;)
T
_______________________________________________
2-Users mailing list
[email protected]
ttp://listserver.u2ug.org/mailman/listinfo/u2-users

_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users

Reply via email to