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

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

Re: [U2] Deep and long indentations vs multiple exit points

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

Re: [U2] Deep and long indentations vs multiple exit points - AD NAUSEUM

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

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

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

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

Re: [U2] Deep and long indentations vs multiple exit points

@listserver.u2ug.org 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

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

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.

RE: [U2] Deep and long indentations vs multiple exit points

, 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

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

Re: [U2] Deep and long indentations vs multiple exit points

@listserver.u2ug.org 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

RE: [U2] Deep and long indentations vs multiple exit points

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

Re: [U2] Deep and long indentations vs multiple exit points

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

Re: [U2] Deep and long indentations vs multiple exit points

You could do this. PROCESS.REC: READ RECORD FROM FILE,ID THEN IF RECORDFLD.1 EQ COND1 AND RECORDFLD.2 EQ COND2 AND RECORDFLD.3 EQ COND3 THEN RECORDFLD.4 = 'PROCESSED' WRITE RECORD TO FILE, ID END IF END IF RETURN Or, you could try: READ RECORD FROM FILE,ID THEN

Re: [U2] Deep and long indentations vs multiple exit points

@listserver.u2ug.org 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

Re: [U2] Deep and long indentations vs multiple exit points

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: u2-users@listserver.u2ug.org Sent: Friday, November 30, 2007 11:38 AM Subject: Re: [U2] Deep and long indentations vs multiple exit points

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 ((RECORDFLD.1 EQ COND1) AND (RECORDFLD.2 EQ COND2) AND (RECORDFLD.3 EQ COND3)) THEN RECORDFLD.4 = 'PROCESSED' END END REPEAT If I was worried about the IF statement getting too long, then I'd do

RE: [U2] Deep and long indentations vs multiple exit points

[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/29/2007 05:41 PM Please respond to u2-users To: u2-users@listserver.u2ug.org cc: Subject:RE: [U2] Deep and long indentations vs multiple exit points But this is so much easier to read (note the liberal use

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

Re: [U2] Deep and long indentations vs multiple exit points

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: u2-users@listserver.u2ug.org Sent: Friday, November 30, 2007 9:36 AM Subject: Re: [U2] Deep and long indentations vs multiple exit points

Re: [U2] Deep and long indentations vs multiple exit points

(508) 747-7261 - Original Message - From: Ray Wurlod [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org 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

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.

RE: [U2] Deep and long indentations vs multiple exit points

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

Re: [U2] Deep and long indentations vs multiple exit points

snip 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. /snip I use CONTINUE all the time when processing records that must meet multiple conditions in a loop. This way my code

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. snip Than see a single case statement that ran across hundreds of lines of code. I've also done

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

RE: [U2] Deep and long indentations vs multiple exit points

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 snip I had to look up the CONTINUE statement. In 25 years I've never used it, and don't even remember seeing it used

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

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

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

RE: [U2] Deep and long indentations vs multiple exit points

] 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

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

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

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.