Re: [U2] Deep and long indentations vs multiple exit points
Marco, I see what you're saying, so I went and looked at some code fresh code I've just written. I see that at its deepest, it goes 5 levels deep, which is pretty close to what you've described. I also noticed something else: In the cases where you could use CONTINUE, all of the ENDs are stacked on top of each other at the bottom of the routine. The fact that you could use CONTINUE pretty much precludes the use of ELSE clauses that actually do something, which eliminates 75% of the issues with nested blocks. Personally, I don't find those situations to be particularly difficult to decipher even when only quickly glancing through code. That tail of ENDs pretty much tells you that you don't need to keep track of the indent levels in your head to sort out the flow later on. I use the AE editor in UV, and I format with "-M0 -I2 -NOCASE", which I think is the only reasonable way to format code. My 5 level deep code is in no way difficult to follow, and I can't see another level or two pushing it over the limit. Dave Barrett, Lawyers' Professional Indemnity Company --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Deep and long indentations vs multiple exit points - AD NAUSEUM
Since AD takes the accusative case, it's AD NAUSEAM (I don't really want to argue JMP instructions, which is all there is once you get to the compiled code.) --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Deep and long indentations vs multiple exit points - AD functionality not bugs
Clif, I appreciated your viewpoint and was glad to see it. I didn't take it that you were singling anyone out, but since I've not sallied forth into the fray, perhaps I was immune from such feelings. Thanks for your contributions as well as those who've made other constructive offerings! Sincerely Best Regards, Richard Lewis --- On Mon 12/03, Clifton Oliver < [EMAIL PROTECTED] > wrote: Apologies to any and all for offense given.--Regards,Clif ___ No banners. No pop-ups. No kidding. Make My Way your home on the Web - http://www.myway.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Deep and long indentations vs multiple exit points - AD functionality not bugs
Sorry, Stuart. I should have completely trimmed the reply quote on my post so it didn't look (as it apparently did) that I was singling out you as the main target of my comments (after the part about guard clauses). It was more of a sociological musing as to how many times over the years we've seen these threads on style, constructs, etc. go on and on. I wonder how many people really change the way they label, or indent, or whatever based on them. I frequently hear comments in my travels from people to the effect of "how do people have time to write all that stuff during the work week; I don't have time to even read them!" I wasn't trying to censor you or anyone else, and I probably should keep such musings to myself. At the very least, I should have worded it better. Apologies to any and all for offense given. -- Regards, Clif On Dec 3, 2007, at 2:14 AM, Boydell, Stuart wrote: Apologies to anyone who thinks I was making unacceptable 'noise' - you're welcome to filter my posts. In my defence - I have always tried to put a guard clause in my posts asserting it's MY opinion - not - thou shalt. If I haven't - it's just a bug in my assertion. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Deep and long indentations vs multiple exit points - AD NAUSEUM
Couple of thoughts. 1. Yes, the 'style' debates tend to be self-serving. 2. I do end up with either feeling good about my techniques or finding out another good technique. 3. By expressing my preferred techniques, others may may experience #2 above. By keeping an open mind, each of us knows how these techniques, both new to us and our own favorites, can weave into our own environments. Many participants seem to manage large shops with 100's of users so every cycle counts. But I'm sure others manage 10-20 users shops. Some have 4GL-style systems with implied rules and requirements. Others may have home-grown systems from the Jurrasic Pick era. Without comparisons, we all function in a vacuum. My 1 cent Mark Johnson - Original Message - From: "Clifton Oliver" <[EMAIL PROTECTED]> To: Sent: Sunday, December 02, 2007 10:55 PM Subject: Re: [U2] Deep and long indentations vs multiple exit points - AD NAUSEUM > Perhaps you might want to expand your search criteria to include "the > last ten years" and examine the use of Guard Clauses. > > Does anyone else on the list find these discussions of "style," "good > practice," etc. to be both out-of-date and an exercise in wasted > bandwidth (not to mention having too much time on one's hands)? > > People being what they are, these discussions always boil down to, > "I'm going to do it my way because I'm right and you are wrong." > > Wouldn't the time be best spent retesting that A/R modification you > plan to push to Production tomorrow night? > > > -- > > Regards, > > Clif > > On Dec 2, 2007, at 5:12 PM, Boydell, Stuart wrote: > > > I'm in complete agreement with the "one way in/out" (OWI-OWO ) > > rule. Out > > of interest, I have searched the net and of the many articles I found > > which cited OWI-OWO, all cited it in the scope of being good > > practice. I > > found one which cites "one way in, multiple|many ways out" with a > > scathing comment. > --- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Deep and long indentations vs multiple exit points
That was an over simplified example. The additional IF tests usually occur in situations where you can neither AND them together nor put them in a CASE structure. For example: PROCESS.ID: READ RECORD1 FROM FILE1, ID ELSE RETURN IF RECORD1 NE COND1 THEN RETURN * Some processing to derive NEXT.ID based on RECORD1 * Initialise some variables here READ RECORD2 FROM FILE2, NEXT.ID ELSE RETURN IF RECORD2 NE RECORD1 THEN RETURN * Some processing to derive NEXT.ID based on RECORD1 and RECORD2 * Initialise some more variables here READ RECORD3 FROM FILE3, NEXT.ID ELSE RETURN COND3 = RECORD1 : RECORD2 IF RECORD3 NE COND3 THEN RETURN * We passed the tests lets do the processing using RECORD1, 2 and 3 and the * the iniatialised variables ... RETURN The final processing block would end up indented a minimum 6 levels without the early RETURNs. Granted you can put the final part in a GOSUB but even that GOSUB is still deeply indented. If you restructure this into SUBs (which I dont oppose per se) you end up with six SUBs that become more difficult to comprehend as you go further down. You would have to scroll up and down to find out at what point some variables came into being. - Original Message From: David A Barrett <[EMAIL PROTECTED]> To: u2-users@listserver.u2ug.org Sent: Friday, 30 November, 2007 4:03:16 PM Subject: Re: [U2] Deep and long indentations vs multiple exit points Curious, I would have done: LOOP WHILE READNEXT ID READ RECORD FROM FILE,ID THEN IF ((RECORD EQ COND1) AND (RECORD EQ COND2) AND (RECORD EQ COND3)) THEN RECORD = 'PROCESSED' END END REPEAT If I was worried about the IF statement getting too long, then I'd do this: LOOP WHILE READNEXT ID READ RECORD FROM FILE,ID THEN ANS1 = (RECORD EQ COND1) ANS2 = (RECORD EQ COND2) ANS3 = (RECORD EQ COND3) IF (ANS1 AND ANS2 AND ANS3) THEN RECORD = 'PROCESSED' END END REPEAT While I'm on it, I probably wouldn't do the looping like that either, I'd do this: MORE = @TRUE LOOP READNEXT ID ELSE MORE = @FALSE WHILE (MORE = @TRUE) DO READ RECORD FROM FILE,ID THEN IF ((RECORD EQ COND1) AND (RECORD EQ COND2) AND (RECORD EQ COND3)) THEN RECORD = 'PROCESSED' END END REPEAT Not that I actually think there's anything wrong with the original way it was done... >I use CONTINUE all the time when processing >records that must meet multiple conditions in a loop. This way my code doesnt >look like 'flying geese'. I will write: > >LOOP WHILE READNEXT ID > READ RECORD >FROM FILE, ID ELSE CONTINUE > IF RECORD NE COND1 THEN CONTINUE > IF >RECORD NE COND2 THEN CONTINUE > IF RECORD NE COND3 THEN >CONTINUE > RECORD = 'PROCESSED' > WRITE RECORD TO FILE, ID >REPEAT >instead of: > >LOOP WHILE READNEXT ID > READ RECORD FROM FILE,ID THEN > IF >RECORD EQ COND1 THEN >IF RECORD EQ COND2 THEN >IF RECORD EQ COND3 THEN > RECORD = 'PROCESSED' >WRITE RECORD TO FILE, ID >END > END > END > END >REPEAT Dave Barrett, Lawyers' Professional Indemnity Company --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ __ Sent from Yahoo! - the World's favourite mail http://uk.mail.yahoo.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Deep and long indentations vs multiple exit points - AD functionality not bugs
One of the reasons I'm subscribed to the list because I'm interested to see how other people do it their way. I've learnt some valuable stuff here. I think contribution to this topic is valid under the banner of technical discussion. But hey if I'm out of line or if the topic is not applicable here then I'm sure the moderator will advise. Apologies to anyone who thinks I was making unacceptable 'noise' - you're welcome to filter my posts. In my defence - I have always tried to put a guard clause in my posts asserting it's MY opinion - not - thou shalt. If I haven't - it's just a bug in my assertion. Peas be with you, Stuart >-Original Message- >Perhaps you might want to expand your search criteria to include "the >last ten years" and examine the use of Guard Clauses. > >Does anyone else on the list find these discussions of "style," "good >practice," etc. to be both out-of-date and an exercise in wasted >bandwidth (not to mention having too much time on one's hands)? > >People being what they are, these discussions always boil down to, >"I'm going to do it my way because I'm right and you are wrong." ** This email message and any files transmitted with it are confidential and intended solely for the use of addressed recipient(s). If you have received this communication in error, please reply to this e-mail to notify the sender of its incorrect delivery and then delete it and your reply. It is your responsibility to check this email and any attachments for viruses and defects before opening or sending them on. Spotless collects information about you to provide and market our services. For information about use, disclosure and access, see our privacy policy at http://www.spotless.com.au Please consider our environment before printing this email. ** --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Deep and long indentations vs multiple exit points
I am a proponent for ON GOSUB's as I use them very often with maintenance programs. For new records, I control the sequence of entered fields, For existing records I use them to cycle through the displayed fields and finally at the bottom line prompt to change a field. SInce I use numbered labels for each field, ie label 100 corresponds to field 1 etc, then it reads pretty easily. Since there could be 10-20 or more fields, it 'looks pretty' with the numbers and you can easily view those fields skipped per each segment. If they were alphanumeric, all of the aforementioned helpers would disappear. Plus, it would be that much more 'wordy' and hard to read quickly. My 1 cent Mark Johnson - Original Message - From: "Trey Miller" <[EMAIL PROTECTED]> To: Sent: Sunday, December 02, 2007 8:43 PM Subject: RE: [U2] Deep and long indentations vs multiple exit points > This typically sticks in the craw of those who feel ON GOSUB is anathema: > > ERROR = 0 > OPERATION = 0 > * > LOOP > BEGIN CASE > CASE ERROR ; EXIT > CASE 1 > OPERATION += 1 > ON OPERATION GOSUB 1000, 2000, 3000, 4000, 5000, 6000 > END CASE > REPEAT > > Personally, I feel alphanumeric subroutine names are anathema; ON/GOSUB is > merely an interesting stylistic decision. > > Harold (Trey) Miller > Ph: (763)-300-8703 > > MaverickSoft, Inc. > 16430 Birch Briar Trail > Plymouth, Minnesota 55447 > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Keith Johnson > (DSLWN) > Sent: Sunday, December 02, 2007 5:59 PM > To: u2-users@listserver.u2ug.org > Subject: RE: [U2] Deep and long indentations vs multiple exit points > > Dave Barret gave this code as an example: > > GOSUB OPERATION.1 > IF (NOT(ERROR)) THEN > GOSUB OPERATION.2 > IF (NOT(ERROR)) THEN > GOSUB OPERATION.3 > IF (NOT(ERROR)) THEN > GOSUB OPEARTION.4 > END > END > END > > What about this version? > > GOSUB OPERATION.1 > IF ERROR ELSE GOSUB OPERATION.2 > IF ERROR ELSE GOSUB OPERATION.4 > IF ERROR ELSE GOSUB OPERATION.5 > > or, more acceptably: > > GOSUB OPERATION.1 > IF GOOD THEN GOSUB OPERATION.2 > IF GOOD THEN GOSUB OPERATION.4 > IF GOOD THEN GOSUB OPERATION.5 > > Which I personally find far more readable than the indented code. > > Regards, Keith "De gustibus non est disputandum" Johnson > --- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ > --- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Deep and long indentations vs multiple exit points
Shouldn't there be a IF OPERATION = LAST.OPERATION THEN EXIT in there after the ON GOSUB? ;) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Trey Miller Sent: Sunday, December 02, 2007 17:43 To: u2-users@listserver.u2ug.org Subject: RE: [U2] Deep and long indentations vs multiple exit points This typically sticks in the craw of those who feel ON GOSUB is anathema: ERROR = 0 OPERATION = 0 * LOOP BEGIN CASE CASE ERROR ; EXIT CASE 1 OPERATION += 1 ON OPERATION GOSUB 1000, 2000, 3000, 4000, 5000, 6000 END CASE REPEAT Personally, I feel alphanumeric subroutine names are anathema; ON/GOSUB is merely an interesting stylistic decision. Harold (Trey) Miller Ph: (763)-300-8703 MaverickSoft, Inc. 16430 Birch Briar Trail Plymouth, Minnesota 55447 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Keith Johnson (DSLWN) Sent: Sunday, December 02, 2007 5:59 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Deep and long indentations vs multiple exit points Dave Barret gave this code as an example: GOSUB OPERATION.1 IF (NOT(ERROR)) THEN GOSUB OPERATION.2 IF (NOT(ERROR)) THEN GOSUB OPERATION.3 IF (NOT(ERROR)) THEN GOSUB OPEARTION.4 END END END What about this version? GOSUB OPERATION.1 IF ERROR ELSE GOSUB OPERATION.2 IF ERROR ELSE GOSUB OPERATION.4 IF ERROR ELSE GOSUB OPERATION.5 or, more acceptably: GOSUB OPERATION.1 IF GOOD THEN GOSUB OPERATION.2 IF GOOD THEN GOSUB OPERATION.4 IF GOOD THEN GOSUB OPERATION.5 Which I personally find far more readable than the indented code. Regards, Keith "De gustibus non est disputandum" Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Deep and long indentations vs multiple exit points
Count me in against unnecessary indenting. With the advent of CONTINUE, that typically saves one indentation in a repeating update routine. At the extreme I've seen code that EVERYTHING is indented, regardless of the extent of the purpose. For example: IF X=1 THEN GOSUB 10 END or IF X=1 THEN Y=2 END Not for nuthin' but is there some taught technique that discourages keeping these smallest of indents as one line. Besides the tired reason "what if you want to add more". My 1 cent Mark Johnson - Original Message - From: "Keith Johnson (DSLWN)" <[EMAIL PROTECTED]> To: Sent: Sunday, December 02, 2007 6:58 PM Subject: RE: [U2] Deep and long indentations vs multiple exit points > Dave Barret gave this code as an example: > > GOSUB OPERATION.1 > IF (NOT(ERROR)) THEN > GOSUB OPERATION.2 > IF (NOT(ERROR)) THEN > GOSUB OPERATION.3 > IF (NOT(ERROR)) THEN > GOSUB OPEARTION.4 > END > END > END > > What about this version? > > GOSUB OPERATION.1 > IF ERROR ELSE GOSUB OPERATION.2 > IF ERROR ELSE GOSUB OPERATION.4 > IF ERROR ELSE GOSUB OPERATION.5 > > or, more acceptably: > > GOSUB OPERATION.1 > IF GOOD THEN GOSUB OPERATION.2 > IF GOOD THEN GOSUB OPERATION.4 > IF GOOD THEN GOSUB OPERATION.5 > > Which I personally find far more readable than the indented code. > > Regards, Keith "De gustibus non est disputandum" Johnson > --- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Deep and long indentations vs multiple exit points - AD NAUSEUM
Perhaps you might want to expand your search criteria to include "the last ten years" and examine the use of Guard Clauses. Does anyone else on the list find these discussions of "style," "good practice," etc. to be both out-of-date and an exercise in wasted bandwidth (not to mention having too much time on one's hands)? People being what they are, these discussions always boil down to, "I'm going to do it my way because I'm right and you are wrong." Wouldn't the time be best spent retesting that A/R modification you plan to push to Production tomorrow night? -- Regards, Clif On Dec 2, 2007, at 5:12 PM, Boydell, Stuart wrote: I'm in complete agreement with the "one way in/out" (OWI-OWO ) rule. Out of interest, I have searched the net and of the many articles I found which cited OWI-OWO, all cited it in the scope of being good practice. I found one which cites "one way in, multiple|many ways out" with a scathing comment. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Deep and long indentations vs multiple exit points
This typically sticks in the craw of those who feel ON GOSUB is anathema: ERROR = 0 OPERATION = 0 * LOOP BEGIN CASE CASE ERROR ; EXIT CASE 1 OPERATION += 1 ON OPERATION GOSUB 1000, 2000, 3000, 4000, 5000, 6000 END CASE REPEAT Personally, I feel alphanumeric subroutine names are anathema; ON/GOSUB is merely an interesting stylistic decision. Harold (Trey) Miller Ph: (763)-300-8703 MaverickSoft, Inc. 16430 Birch Briar Trail Plymouth, Minnesota 55447 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Keith Johnson (DSLWN) Sent: Sunday, December 02, 2007 5:59 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Deep and long indentations vs multiple exit points Dave Barret gave this code as an example: GOSUB OPERATION.1 IF (NOT(ERROR)) THEN GOSUB OPERATION.2 IF (NOT(ERROR)) THEN GOSUB OPERATION.3 IF (NOT(ERROR)) THEN GOSUB OPEARTION.4 END END END What about this version? GOSUB OPERATION.1 IF ERROR ELSE GOSUB OPERATION.2 IF ERROR ELSE GOSUB OPERATION.4 IF ERROR ELSE GOSUB OPERATION.5 or, more acceptably: GOSUB OPERATION.1 IF GOOD THEN GOSUB OPERATION.2 IF GOOD THEN GOSUB OPERATION.4 IF GOOD THEN GOSUB OPERATION.5 Which I personally find far more readable than the indented code. Regards, Keith "De gustibus non est disputandum" Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Deep and long indentations vs multiple exit points
I'm in complete agreement with the "one way in/out" (OWI-OWO ) rule. Out of interest, I have searched the net and of the many articles I found which cited OWI-OWO, all cited it in the scope of being good practice. I found one which cites "one way in, multiple|many ways out" with a scathing comment. And on the subject of Exceptions, not all but arguably the best of the language compilers which implement them ensure the exception clauses are handled correctly. They enforce certain coding standards and style. MV Basic does not do anything like this and so can lead to all sorts of garbage interpretations of an exception. In the example, I'd have been inclined to have compounded the tests into a single (postive) clause: IF (A = B and C = D and E = F) THEN *; update record A single IF statement makes it damn obvious what you're testing. If it's too long a line then break the individual tests up into multiple shorter Boolean variables which can be put in a single IF statement. By the way, doesn't anyone use a READU before updating a record? Cheers, Stuart Boydell >-Original Message- >My view on code structure is very simple: >One way in, one way out. Any block of code, no exceptions. Deal with it. > >I understand the point about deep indentations making code unreadable - >especially in the ubiquitous line editors that some people still insist on >using - but you can still code single entry/single exit point without >nesting anything especially deeply. That's what GOSUB and CALL are for. > >The poster who talked here about modern languages encouraging the throwing >of exceptions, and suggested that multiple exit point code in BASIC emulated >this missed the point that those languages provide exception handling >mechanisms such that you can always engineer a single exit point for each >block, and if you don't, then the language effectively creates one - perhaps >slightly further away - for you. MV BASIC on the other hand provides >absolutely no exception handling other than what is explicitly coded. ** This email message and any files transmitted with it are confidential and intended solely for the use of addressed recipient(s). If you have received this communication in error, please reply to this e-mail to notify the sender of its incorrect delivery and then delete it and your reply. It is your responsibility to check this email and any attachments for viruses and defects before opening or sending them on. Spotless collects information about you to provide and market our services. For information about use, disclosure and access, see our privacy policy at http://www.spotless.com.au Please consider our environment before printing this email. ** --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Deep and long indentations vs multiple exit points
Dave Barret gave this code as an example: GOSUB OPERATION.1 IF (NOT(ERROR)) THEN GOSUB OPERATION.2 IF (NOT(ERROR)) THEN GOSUB OPERATION.3 IF (NOT(ERROR)) THEN GOSUB OPEARTION.4 END END END What about this version? GOSUB OPERATION.1 IF ERROR ELSE GOSUB OPERATION.2 IF ERROR ELSE GOSUB OPERATION.4 IF ERROR ELSE GOSUB OPERATION.5 or, more acceptably: GOSUB OPERATION.1 IF GOOD THEN GOSUB OPERATION.2 IF GOOD THEN GOSUB OPERATION.4 IF GOOD THEN GOSUB OPERATION.5 Which I personally find far more readable than the indented code. Regards, Keith "De gustibus non est disputandum" Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Deep and long indentations vs multiple exit points
Ken: I guess I'm a product of how I've fixed the programs I've inherited. Virtually all of my client's systems pre-exist me and 90% of them are home-grown code instead of being a Package. Thus, I've inherited a great diversity of styles and techniques. Day after day as I sift through this code to derive its purpose, I can see things that help and those that don't. Mind you, 99% of the prior code doesn't have any intermediate comments, barely a blurb at the top of the program regarding date, person and purpose and often has ambiguous names as BREAK.II or CRT SHL.FNDG or the like. Sometimes the only clue is the compile date. Maybe I'm surviving servicing the one-off clients that no-one else wants to deal with due to the inconsistencies. That might explain where I'm coming from. Thanks Mark Johnson - Original Message - From: "Ken Wallis" <[EMAIL PROTECTED]> To: Sent: Sunday, December 02, 2007 5:58 AM Subject: RE: [U2] Deep and long indentations vs multiple exit points > I realise that I've largely been a lurker of late - making a living working > with jBASE pretty much full time now - but I'm afraid I can't let all these > apologists for our spaghetti inheritance slide by unchallenged. > > > > My view on code structure is very simple: > > > > One way in, one way out. Any block of code, no exceptions. Deal with it. > > > > I understand the point about deep indentations making code unreadable - > especially in the ubiquitous line editors that some people still insist on > using - but you can still code single entry/single exit point without > nesting anything especially deeply. That's what GOSUB and CALL are for. > > > > The poster who talked here about modern languages encouraging the throwing > of exceptions, and suggested that multiple exit point code in BASIC emulated > this missed the point that those languages provide exception handling > mechanisms such that you can always engineer a single exit point for each > block, and if you don't, then the language effectively creates one - perhaps > slightly further away - for you. MV BASIC on the other hand provides > absolutely no exception handling other than what is explicitly coded. > Indeed, if you want single exit point code in BASIC you have to work hard > for it, and many of the posters here clearly can't be bothered to. Not that > they're alone - pretty much every poxy 'C' example code segment you read in > an article or text book leaks like a sieve, carrying a weak disclaimer about > error handling code being omitted for the sake of simplicity or clarity - > and I've seen plenty of that sort of 'C' code distributed into production. > Don't worry, I'd have them up against the wall too, come the revolution. It > wouldn't just be the spaghetti BASIC merchants facing the wrong end of a > firing squad when I took over the world! > > > > Meanwhile, Mark, whose posts are almost guaranteed to stir me up, but who I > almost always manage to calm down and ignore, actually brushed up against an > important point during this thread - that the implicit top down evaluation > of CASE statements can sometimes hide the logic that is being coded and > cause grief to future programmers. Don't get me wrong - I'm a firm believer > in CASE statements, but I do think that coders sometimes actively use the > top down evaluation within them to achieve a purpose they don't document, > and that sometimes they just get lucky. In either of these situations, the > maintenance programmer who follows behind can make a simple alteration and > spend days working out what they've broken. > > > > That's my 2 cents worth, and I've got my flame suit buttoned up tight ;^) > > > > Cheers, > > > > Ken > > > > -Original Message- > From: Marco Manyevere > Sent: Thursday, 29 November 2007 3:18 AM > To: u2-users@listserver.u2ug.org > Subject: [U2] Deep and long indentations vs multiple exit points > > > > There has been a lot said recently about styles, standards and good practice > > and I wonder what your take is on deeply indented routines with a common > exit > > point versus unindented routines but with multiple exit points > --- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Deep and long indentations vs multiple exit points
I realise that I've largely been a lurker of late - making a living working with jBASE pretty much full time now - but I'm afraid I can't let all these apologists for our spaghetti inheritance slide by unchallenged. My view on code structure is very simple: One way in, one way out. Any block of code, no exceptions. Deal with it. I understand the point about deep indentations making code unreadable - especially in the ubiquitous line editors that some people still insist on using - but you can still code single entry/single exit point without nesting anything especially deeply. That's what GOSUB and CALL are for. The poster who talked here about modern languages encouraging the throwing of exceptions, and suggested that multiple exit point code in BASIC emulated this missed the point that those languages provide exception handling mechanisms such that you can always engineer a single exit point for each block, and if you don't, then the language effectively creates one - perhaps slightly further away - for you. MV BASIC on the other hand provides absolutely no exception handling other than what is explicitly coded. Indeed, if you want single exit point code in BASIC you have to work hard for it, and many of the posters here clearly can't be bothered to. Not that they're alone - pretty much every poxy 'C' example code segment you read in an article or text book leaks like a sieve, carrying a weak disclaimer about error handling code being omitted for the sake of simplicity or clarity - and I've seen plenty of that sort of 'C' code distributed into production. Don't worry, I'd have them up against the wall too, come the revolution. It wouldn't just be the spaghetti BASIC merchants facing the wrong end of a firing squad when I took over the world! Meanwhile, Mark, whose posts are almost guaranteed to stir me up, but who I almost always manage to calm down and ignore, actually brushed up against an important point during this thread - that the implicit top down evaluation of CASE statements can sometimes hide the logic that is being coded and cause grief to future programmers. Don't get me wrong - I'm a firm believer in CASE statements, but I do think that coders sometimes actively use the top down evaluation within them to achieve a purpose they don't document, and that sometimes they just get lucky. In either of these situations, the maintenance programmer who follows behind can make a simple alteration and spend days working out what they've broken. That's my 2 cents worth, and I've got my flame suit buttoned up tight ;^) Cheers, Ken -Original Message- From: Marco Manyevere Sent: Thursday, 29 November 2007 3:18 AM To: u2-users@listserver.u2ug.org Subject: [U2] Deep and long indentations vs multiple exit points There has been a lot said recently about styles, standards and good practice and I wonder what your take is on deeply indented routines with a common exit point versus unindented routines but with multiple exit points --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Deep and long indentations vs multiple exit points
I agree. On the few cases that I've run into RETURN TO, I've unprogrammed it. Part of the purpose of RETURN TO is that MV doesn't have the POP command whereby you can remove one of the GOSUB stack references and 'return to' the prior GOSUB statement. Being one who can use GOTO properly and can mix it with GOSUB and CALL for readable code, I don't use RETURN TO. My 1 cent Mark Johnson - Original Message - From: "Susan Lynch" <[EMAIL PROTECTED]> To: Sent: Friday, November 30, 2007 11:38 AM Subject: Re: [U2] Deep and long indentations vs multiple exit points > Ray, at the risk of another 'holy war', please don't encourage the use of > "RETURN TO" - particularly with large complex groups of programs with lots > of subroutines, this can lead to "return stack overflow" scenarios that are > extremely hard to debug (having cleaned up a lot of these as the 'next > programmer' on site, I cringed when I read that). I am not an anti-GOTO > Nazi, if used sparingly and with good reason, but RETURN TO is, in my > experience, a debugging nightmare waiting to happen. > > Susan M. Lynch > F.W. Davison & Company, Inc. > 10 Cordage Park Circle, Suite 200 > Plymouth, MA 02360-7318 > (508) 747-7261 > > - Original Message - > From: "Ray Wurlod" <[EMAIL PROTECTED]> > To: > Sent: Thursday, November 29, 2007 5:11 PM > Subject: Re: [U2] Deep and long indentations vs multiple exit points > > > >A third possibility is to allow GOTO ERROREXIT (single exit point) - or > >even RETURN TO ERROREXIT - in error handling code. This substantially > >reduces the number of levels of indentation required. > > --- > > u2-users mailing list > > u2-users@listserver.u2ug.org > > To unsubscribe please visit http://listserver.u2ug.org/ > --- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Deep and long indentations vs multiple exit points
Yes, but the example had only 3 tested conditions. Changing the number to suit a method invalidates the original comparison. It's like 5+5 versus 5+5+5+5+5+5+5+5+5+5+5 whereby you change your method from adding to multiplying. If it's argued that every IF statement 'could' grow to a 'huge' number' then throw away the IF alltogether and your program looks like this: BEGIN CASE CASE X=1 GOSUB 100 END CASE Certainly compilable but distracting. I agree, in the case of a long string of parsing, CASE is preferred. I write tons of EDI parsers and they all case CASE. In the big picture, especially in the example we are both working on, IF statements generally conclude on one OR the other condition. If there's 3 or more, and only one should prevail, then CASE wins. My 3 cents. Mark Johnson - Original Message - From: "Dianne Ackerman" <[EMAIL PROTECTED]> To: Sent: Friday, November 30, 2007 10:38 AM Subject: Re: [U2] Deep and long indentations vs multiple exit points > Mark, > Although I usually agree with you, this time I have to disagree. Using > a CASE statement in this way seems a very clear way to handle something, > especially when you're checking for a huge number of reasons to > "disqualify" something from happening. Have you ever programmed the > Federal Financial Aid calculations? They have tons of things to check > for before allowing a calculation. In my opinion, something like > > BEGIN CASE > CASE FIRST.DISQUAL.CHECK; NULL > CASE SECOND.DISQUAL.CHECK; NULL > ... > ... > CASE TWENTIETH.DISQUAL.CHECK; NULL > CASE 1 >DO MONSTROUS CALC > END CASE > > is much cleaner and easier to read (and modify every single year) than a > huge IF-THEN statement! > -Dianne > > MAJ Programming wrote: > > >IMHO, using CASE as a replacement for IF's is extraneous. Meaning a harder > >alternate than what should be the simpler form. CASE statements resolve to > >being IF statements when compiled anyway. > > > >CASE statements are best used for their original purpose. That is to > >evaluate multiple conditions and only accept the first valid one and provide > >an easy way to not consider the latter tests. Thus, each separate CASE > >statement should have the thought process of individually being used instead > >of just cascading all the negatives. > --- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Deep and long indentations vs multiple exit points
Ray, at the risk of another 'holy war', please don't encourage the use of "RETURN TO" - particularly with large complex groups of programs with lots of subroutines, this can lead to "return stack overflow" scenarios that are extremely hard to debug (having cleaned up a lot of these as the 'next programmer' on site, I cringed when I read that). I am not an anti-GOTO Nazi, if used sparingly and with good reason, but RETURN TO is, in my experience, a debugging nightmare waiting to happen. Susan M. Lynch F.W. Davison & Company, Inc. 10 Cordage Park Circle, Suite 200 Plymouth, MA 02360-7318 (508) 747-7261 - Original Message - From: "Ray Wurlod" <[EMAIL PROTECTED]> To: Sent: Thursday, November 29, 2007 5:11 PM Subject: Re: [U2] Deep and long indentations vs multiple exit points A third possibility is to allow GOTO ERROREXIT (single exit point) - or even RETURN TO ERROREXIT - in error handling code. This substantially reduces the number of levels of indentation required. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Deep and long indentations vs multiple exit points
Mark, Although I usually agree with you, this time I have to disagree. Using a CASE statement in this way seems a very clear way to handle something, especially when you're checking for a huge number of reasons to "disqualify" something from happening. Have you ever programmed the Federal Financial Aid calculations? They have tons of things to check for before allowing a calculation. In my opinion, something like BEGIN CASE CASE FIRST.DISQUAL.CHECK; NULL CASE SECOND.DISQUAL.CHECK; NULL ... ... CASE TWENTIETH.DISQUAL.CHECK; NULL CASE 1 DO MONSTROUS CALC END CASE is much cleaner and easier to read (and modify every single year) than a huge IF-THEN statement! -Dianne MAJ Programming wrote: IMHO, using CASE as a replacement for IF's is extraneous. Meaning a harder alternate than what should be the simpler form. CASE statements resolve to being IF statements when compiled anyway. CASE statements are best used for their original purpose. That is to evaluate multiple conditions and only accept the first valid one and provide an easy way to not consider the latter tests. Thus, each separate CASE statement should have the thought process of individually being used instead of just cascading all the negatives. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Deep and long indentations vs multiple exit points
>For my money, the CASE statement, sensibly used, is much better than >multiple IF statements Agreed. Let the compiler work it out. Charles Shaffer Senior Analyst NTN-Bower Corporation --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Deep and long indentations vs multiple exit points
Curious, I would have done: LOOP WHILE READNEXT ID READ RECORD FROM FILE,ID THEN IF ((RECORD EQ COND1) AND (RECORD EQ COND2) AND (RECORD EQ COND3)) THEN RECORD = 'PROCESSED' END END REPEAT If I was worried about the IF statement getting too long, then I'd do this: LOOP WHILE READNEXT ID READ RECORD FROM FILE,ID THEN ANS1 = (RECORD EQ COND1) ANS2 = (RECORD EQ COND2) ANS3 = (RECORD EQ COND3) IF (ANS1 AND ANS2 AND ANS3) THEN RECORD = 'PROCESSED' END END REPEAT While I'm on it, I probably wouldn't do the looping like that either, I'd do this: MORE = @TRUE LOOP READNEXT ID ELSE MORE = @FALSE WHILE (MORE = @TRUE) DO READ RECORD FROM FILE,ID THEN IF ((RECORD EQ COND1) AND (RECORD EQ COND2) AND (RECORD EQ COND3)) THEN RECORD = 'PROCESSED' END END REPEAT Not that I actually think there's anything wrong with the original way it was done... >I use CONTINUE all the time when processing >records that must meet multiple conditions in a loop. This way my code doesnt >look like 'flying geese'. I will write: > >LOOP WHILE READNEXT ID > READ RECORD >FROM FILE, ID ELSE CONTINUE > IF RECORD NE COND1 THEN CONTINUE > IF >RECORD NE COND2 THEN CONTINUE > IF RECORD NE COND3 THEN >CONTINUE > RECORD = 'PROCESSED' > WRITE RECORD TO FILE, ID >REPEAT >instead of: > >LOOP WHILE READNEXT ID > READ RECORD FROM FILE,ID THEN > IF >RECORD EQ COND1 THEN > IF RECORD EQ COND2 THEN >IF RECORD EQ COND3 THEN > RECORD = 'PROCESSED' >WRITE RECORD TO FILE, ID >END > END > END > END >REPEAT Dave Barrett, Lawyers' Professional Indemnity Company --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Deep and long indentations vs multiple exit points
IMHO, using CASE as a replacement for IF's is extraneous. Meaning a harder alternate than what should be the simpler form. CASE statements resolve to being IF statements when compiled anyway. CASE statements are best used for their original purpose. That is to evaluate multiple conditions and only accept the first valid one and provide an easy way to not consider the latter tests. Thus, each separate CASE statement should have the thought process of individually being used instead of just cascading all the negatives. I believe the AND's in the IF statement are doing exactly what they are intended to do. By expanding it into a CASE sequence distracts the reader. BTW, one of my pet peeves with CASE statements is the blind addition of these lines at the end: CASE 1 ; NULL. While there are debates surrounding the use and value of NULL, adding CASE 1 ; NULL for no purpose than to look pretty is, as some say, a waste of cycles. It also distracts the programmer from considering that there is a final catch all scenario when there really isn't any. It's like IF X=1 THEN GOSUB 100 ELSE NULL. Not necessary. My 2 cents. Mark Johnson BTW2. The use of END IF indicates someone coming from another non-MV environment as END IF isn't MV required. I don't even know if it compiles. - Original Message - From: "Colin Jennings" <[EMAIL PROTECTED]> To: Sent: Friday, November 30, 2007 9:36 AM Subject: Re: [U2] Deep and long indentations vs multiple exit points > > You could do this. > > > > PROCESS.REC: > > > > > > READ RECORD FROM FILE,ID THEN > > IF RECORD EQ COND1 AND RECORD EQ COND2 AND RECORD > > EQ COND3 THEN > > RECORD = 'PROCESSED' > > WRITE RECORD TO FILE, ID > > END IF > > END IF > > > > RETURN > > > Or, you could try: > > READ RECORD FROM FILE,ID THEN >BEGIN CASE >CASE RECORD NE COND1 >CASE RECORD NE COND2 >CASE RECORD NE COND3 >CASE 1 > RECORD = "PROCESSED" > WRITE RECORD ON FILE, ID >END CASE > END > > For my money, the CASE statement, sensibly used, is much better than > multiple IF statements > > Colin. > --- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Deep and long indentations vs multiple exit points
You could do this. PROCESS.REC: READ RECORD FROM FILE,ID THEN IF RECORD EQ COND1 AND RECORD EQ COND2 AND RECORD EQ COND3 THEN RECORD = 'PROCESSED' WRITE RECORD TO FILE, ID END IF END IF RETURN Or, you could try: READ RECORD FROM FILE,ID THEN BEGIN CASE CASE RECORD NE COND1 CASE RECORD NE COND2 CASE RECORD NE COND3 CASE 1 RECORD = "PROCESSED" WRITE RECORD ON FILE, ID END CASE END For my money, the CASE statement, sensibly used, is much better than multiple IF statements Colin. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Deep and long indentations vs multiple exit points
You could do this.
PROCESS.REC:
READ RECORD FROM FILE,ID THEN
IF RECORD EQ COND1 AND RECORD EQ COND2 AND RECORD
EQ COND3 THEN
RECORD = 'PROCESSED'
WRITE RECORD TO FILE, ID
END IF
END IF
RETURN
The If statement is a little long, but there is one exit point, no nested
IF's, and less lines of code. I might even be tempted to put the IF
statement in the WHILE LOOP and not use a subroutine.
Is the IF statement to hard to read? I don't think so, but others might
disagree..
I do use multiple exit points sometimes, but I was trained not to and
avoid them unless there is a compelling reason. I suspect that they are
fine in the initial application, but someone else doing maintenance later
might miss something that the original author took for granted.
Charles Shaffer
Senior Analyst
NTN-Bower Corporation
"Womack, Adrian" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
11/29/2007 05:41 PM
Please respond to u2-users
To:
cc:
Subject: RE: [U2] Deep and long indentations vs multiple exit
points
But this is so much easier to read (note the liberal use of blank lines
making the conditions easy to spot):
LOOP
WHILE READNEXT ID
GOSUB PROCESS.REC
REPEAT
RETURN
PROCESS.REC:
READ RECORD FROM FILE,ID
ELSE RETURN
IF RECORD NE COND1
THEN RETURN
IF RECORD NE COND2
THEN RETURN
IF RECORD NE COND3
THEN RETURN
RECORD = 'PROCESSED'
WRITE RECORD TO FILE, ID
RETURN
(hopefully the mail list didn't screw with the formatting)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Marco Manyevere
Sent: Friday, 30 November 2007 1:46 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] Deep and long indentations vs multiple exit points
I had to look up the "CONTINUE" statement. In 25 years I've never used
it, and don't even remember seeing it used. Now I know what it does I
think it should be banned.
I use CONTINUE all the time when processing records that must meet
multiple conditions in a loop. This way my code doesnt look like 'flying
geese'. I will write:
LOOP WHILE READNEXT ID
READ RECORD
FROM FILE, ID ELSE CONTINUE
IF RECORD NE COND1 THEN CONTINUE
IF
RECORD NE COND2 THEN CONTINUE
IF RECORD NE COND3 THEN
CONTINUE
RECORD = 'PROCESSED'
WRITE RECORD TO FILE, ID
REPEAT
instead of:
LOOP WHILE READNEXT ID
READ RECORD FROM FILE,ID THEN
IF
RECORD EQ COND1 THEN
IF RECORD EQ COND2 THEN
IF RECORD EQ COND3 THEN
RECORD = 'PROCESSED'
WRITE RECORD TO FILE, ID
END
END
END
END
REPEAT
___
Yahoo! Answers -
Got a question? Someone out there knows the answer. Try it now.
http://uk.answers.yahoo.com/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
DISCLAIMER:
Disclaimer. This e-mail is private and confidential. If you are not the
intended recipient, please advise us by return e-mail immediately, and
delete the e-mail and any attachments without using or disclosing the
contents in any way. The views expressed in this e-mail are those of the
author, and do not represent those of this company unless this is clearly
indicated. You should scan this e-mail and any attachments for viruses.
This company accepts no liability for any direct or indirect damage or
loss resulting from the use of any attachments to this e-mail.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
This email was Anti Virus checked by Astaro Security Gateway.
http://www.astaro.com
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Deep and long indentations vs multiple exit points
But this is so much easier to read (note the liberal use of blank lines making the conditions easy to spot): LOOP WHILE READNEXT ID GOSUB PROCESS.REC REPEAT RETURN PROCESS.REC: READ RECORD FROM FILE,ID ELSE RETURN IF RECORD NE COND1 THEN RETURN IF RECORD NE COND2 THEN RETURN IF RECORD NE COND3 THEN RETURN RECORD = 'PROCESSED' WRITE RECORD TO FILE, ID RETURN (hopefully the mail list didn't screw with the formatting) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marco Manyevere Sent: Friday, 30 November 2007 1:46 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Deep and long indentations vs multiple exit points I had to look up the "CONTINUE" statement. In 25 years I've never used it, and don't even remember seeing it used. Now I know what it does I think it should be banned. I use CONTINUE all the time when processing records that must meet multiple conditions in a loop. This way my code doesnt look like 'flying geese'. I will write: LOOP WHILE READNEXT ID READ RECORD FROM FILE, ID ELSE CONTINUE IF RECORD NE COND1 THEN CONTINUE IF RECORD NE COND2 THEN CONTINUE IF RECORD NE COND3 THEN CONTINUE RECORD = 'PROCESSED' WRITE RECORD TO FILE, ID REPEAT instead of: LOOP WHILE READNEXT ID READ RECORD FROM FILE,ID THEN IF RECORD EQ COND1 THEN IF RECORD EQ COND2 THEN IF RECORD EQ COND3 THEN RECORD = 'PROCESSED' WRITE RECORD TO FILE, ID END END END END REPEAT ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ DISCLAIMER: Disclaimer. This e-mail is private and confidential. If you are not the intended recipient, please advise us by return e-mail immediately, and delete the e-mail and any attachments without using or disclosing the contents in any way. The views expressed in this e-mail are those of the author, and do not represent those of this company unless this is clearly indicated. You should scan this e-mail and any attachments for viruses. This company accepts no liability for any direct or indirect damage or loss resulting from the use of any attachments to this e-mail. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Deep and long indentations vs multiple exit points
A third possibility is to allow GOTO ERROREXIT (single exit point) - or even RETURN TO ERROREXIT - in error handling code. This substantially reduces the number of levels of indentation required. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Deep and long indentations vs multiple exit points
My rule of thumb is that I should be able to see on the same page the structure for IF/END, LOOP/REPEAT, READ/END, FOR/NEXT, etc. Otherwise the block in between becomes a good candidate for a GOSUB. Than see a single case statement that ran across hundreds of lines of code. I've also done stuff like this: GOSUB OPERATION.1 IF (NOT(ERROR)) THEN GOSUB OPERATION.2 IF (NOT(ERROR)) THEN GOSUB OPERATION.3 IF (NOT(ERROR)) THEN GOSUB OPEARTION.4 END END END Which I think nicely splits out the control structure and makes it clear at a glance how the program works. ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Deep and long indentations vs multiple exit points
I had to look up the "CONTINUE" statement. In 25 years I've never used it, and don't even remember seeing it used. Now I know what it does I think it should be banned. I use CONTINUE all the time when processing records that must meet multiple conditions in a loop. This way my code doesnt look like 'flying geese'. I will write: LOOP WHILE READNEXT ID READ RECORD FROM FILE, ID ELSE CONTINUE IF RECORD NE COND1 THEN CONTINUE IF RECORD NE COND2 THEN CONTINUE IF RECORD NE COND3 THEN CONTINUE RECORD = 'PROCESSED' WRITE RECORD TO FILE, ID REPEAT instead of: LOOP WHILE READNEXT ID READ RECORD FROM FILE,ID THEN IF RECORD EQ COND1 THEN IF RECORD EQ COND2 THEN IF RECORD EQ COND3 THEN RECORD = 'PROCESSED' WRITE RECORD TO FILE, ID END END END END REPEAT ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Deep and long indentations vs multiple exit points
> I much prefer the multiple exit point method, it makes the > code a lot easier to read. I call this "Pragmatic Programming". Anytime a "standard" interferes with the clarity and/or function of the code, it is time to find an alternate way. Only a few things are absolute, like "GOTO is a four-letter word". For example, I usually test for positive conditions and put subsequent code under a THEN clause. But if that results in the outer IF statement's closing END being more that two screen pages of code away, I deem it too hard to understand and start testing for negatives with immediate RETURNs. === Norman Morgan <> [EMAIL PROTECTED] <> http://www.brake.com === Pain is your body's way of saying, "Hey! Stop that!!" === > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Womack, Adrian > Sent: Wednesday, November 28, 2007 5:52 PM > To: u2-users@listserver.u2ug.org > Subject: RE: [U2] Deep and long indentations vs multiple exit points > > > Prime examples are when you are looping through a file but > only want to process certain records that pass a lot of > conditions, it so much easier to test each condition > individually and then RETURN immediately. > > Some people blindly want to stick with a "single exit point", > but as I see it, an early RETURN is basically an "exception" > which the more advanced languages allow and encourage. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Deep and long indentations vs multiple exit points
I'm very old school and learned my structured programming in PASCAL. The cardinal rule is that you enter every block of code from the top, and you exit it from the bottom. No one ever got hurt doing this. I can only remember one case in recent history where I actually used mulitple exit points. The routine was supposed to decide if a client was eligible for something. I set the answer to "No" at the top the routine, and "Yes" at the bottom. There were all kinds of tests in between. Failure of any test executed a "RETURN" statement, before it reached the line of code that set the answer to "Yes". I did it that way because I thought it was actually clearer than embedded IF statements. We needed to make a modification a few years later to suspend eligibility for all customers for a time. That could have been achieved by simply putting a RETURN near the top of the routine. Curiously, the programmer assigned that task seemed simply unable to comprehend how the routine worked, and made a mess of it. He would have had no problem dealing with a set of embedded IF's. I had to look up the "CONTINUE" statement. In 25 years I've never used it, and don't even remember seeing it used. Now I know what it does I think it should be banned. My approach to situtations like this, where the control structure around a block gets so split up that it's hard to see at a glance what it's doing, is to put the functional block into an internal subroutine. I'd much rather see: BEGIN CASE CASE OPTION 1 GOSUB OPTION.1.FUNCTIONAL.CODE CASE OPTION 2 GOSUB OPTION.2.FUNCTIONAL.CODE CASE OPTION 3 GOSUB OPTION.3.FUNCTIONAL.CODE END CASE Than see a single case statement that ran across hundreds of lines of code. I've also done stuff like this: GOSUB OPERATION.1 IF (NOT(ERROR)) THEN GOSUB OPERATION.2 IF (NOT(ERROR)) THEN GOSUB OPERATION.3 IF (NOT(ERROR)) THEN GOSUB OPEARTION.4 END END END Which I think nicely splits out the control structure and makes it clear at a glance how the program works. Dave Barrett, Lawyers' Professional Indemnity Company --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Deep and long indentations vs multiple exit points
I much prefer the multiple exit point method, it makes the code a lot easier to read. Prime examples are when you are looping through a file but only want to process certain records that pass a lot of conditions, it so much easier to test each condition individually and then RETURN immediately. Some people blindly want to stick with a "single exit point", but as I see it, an early RETURN is basically an "exception" which the more advanced languages allow and encourage. DISCLAIMER: Disclaimer. This e-mail is private and confidential. If you are not the intended recipient, please advise us by return e-mail immediately, and delete the e-mail and any attachments without using or disclosing the contents in any way. The views expressed in this e-mail are those of the author, and do not represent those of this company unless this is clearly indicated. You should scan this e-mail and any attachments for viruses. This company accepts no liability for any direct or indirect damage or loss resulting from the use of any attachments to this e-mail. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Deep and long indentations vs multiple exit points
I try as hard as possible to keep the subr's in the same order as they are called (not always possible with conditions in the calling portion of the program). Therefore someone just reading down the program can get a good feeling for what's happening if that's the way they like to read it. I *definitely* prefer the structured format. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] >I've seen programs that have 40 lines of main program code and >99% of them are GOSUBs. That is just a horrible way to design an >application, IMO. That is interesting. I prefer the main routine to be a stack of well named routine or function calls with minimal flow control and no detail. I find it makes debugging easier to push the detail to the bottom. Different strokes... Charles Shaffer Senior Analyst NTN-Bower Corporation --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Deep and long indentations vs multiple exit points
>I've seen programs that have 40 lines of main program code and >99% of them are GOSUBs. That is just a horrible way to design an >application, IMO. That is interesting. I prefer the main routine to be a stack of well named routine or function calls with minimal flow control and no detail. I find it makes debugging easier to push the detail to the bottom. Different strokes... Charles Shaffer Senior Analyst NTN-Bower Corporation --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Deep and long indentations vs multiple exit points
While I agree that modularity is the future path to easy redesigns, over modularizing an application can make the code even more difficult to comprehend than a top-down program with 10K lines and GOs every 20 lines. Anytime a section of code can be used elsewhere in the same program, but the scope of the code is too narrow to be changed to a global routine, then I make it an internal subroutine. Some people just don't know when to say when, though. I've seen programs that have 40 lines of main program code and 99% of them are GOSUBs. That is just a horrible way to design an application, IMO. Yes, it modularizes. It also makes the debugging developer continually jump from top to bottom of a 30K line program, trying to determine which of the 100 routines is being called at a certain run-time point, so you can find that one gremlin in the program that keeps bonking out. Even the best of comments don't always help here. When the code is broken up to that level of modularity, even single-use calculations can become internal subs in some people's minds. Glen Batchelor IT Director All-Spec Industries phone: (910) 332-0424 fax: (910) 763-5664 E-mail: [EMAIL PROTECTED] Web: http://www.all-spec.com Blog: http://blog.all-spec.com > -Original Message- > From: [EMAIL PROTECTED] [mailto:owner-u2- > [EMAIL PROTECTED] On Behalf Of Bessel, Karen > Sent: Wednesday, November 28, 2007 12:31 PM > To: u2-users@listserver.u2ug.org > Subject: RE: [U2] Deep and long indentations vs multiple exit points > > Subroutinize, subroutinize, subroutinize > > Flying geese should be avoided whenever possible. Those deep indents are > nearly impossible to read/maintain later on. > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Marco Manyevere > Sent: Wednesday, November 28, 2007 10:18 AM > To: u2-users@listserver.u2ug.org > Subject: [U2] Deep and long indentations vs multiple exit points > > There has been a lot said recently about styles, standards and good > practice > and I wonder what your take is on deeply indented routines with a common > exit > point versus unindented routines but with multiple exit points. I almost > always prefer the later and find it much easier to follow. I come > accross > several routines or GOSUBs that get indented from line 1 right up to the > end > and I always change that to an early return and remove the indentation. > Below > are some examples: > > PROCESS.ID: > READ RECORD FROM FILE, ID THEN > * Several > lines of indented code to calculate DESIRED.VALUE > IF RECORD EQ > DESIRED.VALUE THEN > * Several lines of even more indented code > END > END > RETURN > > versus: > > PROCESS.ID: > READ RECORD FROM FILE, ID ELSE > RETURN > END > * Several lines of unindented code to calculate DESIRED.VALUE > IF > RECORD NE DESIRED.VALUE THEN > RETURN > END > * Several lines of > unindented processing code > RETURN > > Or > > LOOP > READ RECORD FROM FILE, ID THEN > IF RECORD EQ 1 THEN > * Processing code > END > END > REPEAT UNTIL SOMECONDITION > > Versus: > > LOOP > READ RECORD FROM FILE, ID > ELSE > CONTINUE > END > IF RECORD NE 1 THEN > CONTINUE > END > * Processing code > REPEAT UNTIL SOMECONDITION > ___ > Yahoo! Answers - > Got a question? Someone out there knows the answer. Try it > now. > http://uk.answers.yahoo.com/ > --- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ > --- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Deep and long indentations vs multiple exit points
If I'm programming "on my own" I'll usually adopt the RETURN instead of continuing, just because it's *faster* to not process the rest of the statements that don't need processing. However, I have been told NOT TO DO THAT by someone who was substantially IRKED by multiple returns, and instead adopted the IF NOT(ERROR) THEN Stuff END IF NOT(ERROR) THEN Stuff END Approach. ERROR being a standard system variable on MT500, M2K's way of passing different ways to abort/handle screen prompt processing scenarios. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Anthony Youngman Sent: Wednesday, November 28, 2007 08:46 To: 'u2-users@listserver.u2ug.org' Subject: RE: [U2] Deep and long indentations vs multiple exit points I must admit I prefer multiple exit points, but I'll throw a third variant into the mix ... OK = TRUE IF OK THEN Various statements that set OK to false if there's an error END IF OK THEN More statements that set OK to false if there's an error END --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Deep and long indentations vs multiple exit points
Subroutinize, subroutinize, subroutinize Flying geese should be avoided whenever possible. Those deep indents are nearly impossible to read/maintain later on. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marco Manyevere Sent: Wednesday, November 28, 2007 10:18 AM To: u2-users@listserver.u2ug.org Subject: [U2] Deep and long indentations vs multiple exit points There has been a lot said recently about styles, standards and good practice and I wonder what your take is on deeply indented routines with a common exit point versus unindented routines but with multiple exit points. I almost always prefer the later and find it much easier to follow. I come accross several routines or GOSUBs that get indented from line 1 right up to the end and I always change that to an early return and remove the indentation. Below are some examples: PROCESS.ID: READ RECORD FROM FILE, ID THEN * Several lines of indented code to calculate DESIRED.VALUE IF RECORD EQ DESIRED.VALUE THEN * Several lines of even more indented code END END RETURN versus: PROCESS.ID: READ RECORD FROM FILE, ID ELSE RETURN END * Several lines of unindented code to calculate DESIRED.VALUE IF RECORD NE DESIRED.VALUE THEN RETURN END * Several lines of unindented processing code RETURN Or LOOP READ RECORD FROM FILE, ID THEN IF RECORD EQ 1 THEN * Processing code END END REPEAT UNTIL SOMECONDITION Versus: LOOP READ RECORD FROM FILE, ID ELSE CONTINUE END IF RECORD NE 1 THEN CONTINUE END * Processing code REPEAT UNTIL SOMECONDITION ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Deep and long indentations vs multiple exit points
I like only one exit per subroutine. Deeply indented code can be minimized by use of CASE statements and GOSUBs. Thus keeping readability and enhancing maintainability. Thanks, David A. Green www.dagconsulting.com (480) 813-1725 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Deep and long indentations vs multiple exit points
I must admit I prefer multiple exit points, but I'll throw a third variant into the mix ... OK = TRUE IF OK THEN Various statements that set OK to false if there's an error END IF OK THEN More statements that set OK to false if there's an error END Rinse and repeat RETURN Cheers, Wol -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marco Manyevere Sent: 28 November 2007 16:18 To: u2-users@listserver.u2ug.org Subject: [U2] Deep and long indentations vs multiple exit points There has been a lot said recently about styles, standards and good practice and I wonder what your take is on deeply indented routines with a common exit point versus unindented routines but with multiple exit points. I almost always prefer the later and find it much easier to follow. I come accross several routines or GOSUBs that get indented from line 1 right up to the end and I always change that to an early return and remove the indentation. Below are some examples: PROCESS.ID: READ RECORD FROM FILE, ID THEN * Several lines of indented code to calculate DESIRED.VALUE IF RECORD EQ DESIRED.VALUE THEN * Several lines of even more indented code END END RETURN versus: PROCESS.ID: READ RECORD FROM FILE, ID ELSE RETURN END * Several lines of unindented code to calculate DESIRED.VALUE IF RECORD NE DESIRED.VALUE THEN RETURN END * Several lines of unindented processing code RETURN Or LOOP READ RECORD FROM FILE, ID THEN IF RECORD EQ 1 THEN * Processing code END END REPEAT UNTIL SOMECONDITION Versus: LOOP READ RECORD FROM FILE, ID ELSE CONTINUE END IF RECORD NE 1 THEN CONTINUE END * Processing code REPEAT UNTIL SOMECONDITION ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Deep and long indentations vs multiple exit points
There has been a lot said recently about styles, standards and good practice and I wonder what your take is on deeply indented routines with a common exit point versus unindented routines but with multiple exit points. I almost always prefer the later and find it much easier to follow. I come accross several routines or GOSUBs that get indented from line 1 right up to the end and I always change that to an early return and remove the indentation. Below are some examples: PROCESS.ID: READ RECORD FROM FILE, ID THEN * Several lines of indented code to calculate DESIRED.VALUE IF RECORD EQ DESIRED.VALUE THEN * Several lines of even more indented code END END RETURN versus: PROCESS.ID: READ RECORD FROM FILE, ID ELSE RETURN END * Several lines of unindented code to calculate DESIRED.VALUE IF RECORD NE DESIRED.VALUE THEN RETURN END * Several lines of unindented processing code RETURN Or LOOP READ RECORD FROM FILE, ID THEN IF RECORD EQ 1 THEN * Processing code END END REPEAT UNTIL SOMECONDITION Versus: LOOP READ RECORD FROM FILE, ID ELSE CONTINUE END IF RECORD NE 1 THEN CONTINUE END * Processing code REPEAT UNTIL SOMECONDITION ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
