Come on guys 'IF X ELSE blah' - is it really that bad/hard - it is logic and we are computer programmers, we should be able to figure out a lot tougher stuff than that ;)
Rgds Symeon. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming Sent: 03 August 2007 01:32 To: [email protected] Subject: Re: [U2] RE: Cleaner Case Statement Then you must have the luzury of programming from scratch. I support roughly 15 clients worth of software written in various platforms with some source code stretching as far back as 1974. Yes, 33 year old code. I certainly program from scratch as well. But the incredibly large installed base uses IF X=1 THEN GOSUB 100 instead of the ALL_OK=X=1 then IF ALL_OK THEN DO_SOMETHING Again, don't read into the literal nature of the example. The deviated topic was avoiding the ELSE as the first condition in IF X=100 ELSE GOSUB 100 which is historically inconsistent. My 1 cent Mark Johnson ----- Original Message ----- From: "Jeff Flynt" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Tuesday, July 31, 2007 10:14 PM Subject: RE: [U2] RE: Cleaner Case Statement > I typically use the full form of each structured statement and lay it out in > the indented format. This is just coding laziness since I hate having to go > back and add that missing branch of an if statement when I am 500 lines of > code into it and several indent levels deep. > > This includes using the default branch of a case - the "old fashioned" CASE > 1 clause. How I do it differently is in the wording. I like my code to be > self documenting and consistent. Using a variable such as X and a label such > as 100 is definitely a "little dated." > > I used to, in the old days, create an equate for TRUE and set it to 1 = 1. > And I would equate OTHERWISE to TRUE. I then have a CASE OTHERWISE, and I > always have a CASE OTHERWISE on every case statement - even if it had no > action. These days, I get lazy and just use CASE @TRUE since it would be an > arrogant assumption of me to assume that 1 is true. At best it is very old > school and poor form. But having the CASE @TRUE branch there is my > signature; Coding every structured path is my style. > > On the other hand, while I don't do this a lot, I don't have any problem > with the using the form IF X = 1 ELSE GOSUB 100 type statement. I do think > it is dreadfully cryptic. I seriously hate dealing with this kind of code. > What is X? What is 100? YIKES! And I like to avoid single use > subroutines/GOSUBs when possible - not because they are inherently bad, but > because they are parameterless and if you use it once why complicate the > issue? I usually just put the code inline, but I occasionally don't if it > would improve the self documenting nature of the code. > > Anyway, if X were a status code say, and we wanted to watch for a status of > 1 I might do something like this: > > ALL_IS_WELL_PROCEED = X = 1 ; * This "X" business is just to match the > previous example. > ... > Some code goes here including possibly status code ALL_IS_WELL_PROCEED > updates > ... > IF ALL_IS_WELL_PROCEED ELSE GOSUB HANDLE_PROBLEM > > To me that reads like instructions to bake a cake, and anybody can "see" the > intension. I do not have to have a degree in cryptography to read this > regardless of how I set it up. It is 1,000,000 times easier to read then the > suggested alternative IF X#1 THEN GOSUB 100 or IF X=1 ELSE GOSUB 100. Both > are equally despicable. Either way the code is so obfuscated it is to be > avoided at all cost! > > So why argue about how many angels can dance on the head of a pin when you > cannot see the mountains in your molehills? It's like, is it better to pick > you nose in public with your right hand or your left hand...? > > So, while I jest about this, I do have an ounce of seriousness about it. > Everybody is so "my way is better..." And it just isn't. I include my own > style in this. My way is only better if you like it better. Flatter > whomever you like. Copy them! And deal with the god awful code that is out > there... > > This thread should be closed. > > PS: I wonder if I am the horrible guy who coded the nested OPEN statements. > I did do that once upon a time, long ago when I was a MADIC programmer. I > was really hard core then. I don't do that anymore, but only because I am > lazy. And I still don't have a problem with it. > > > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming > Sent: Friday, July 27, 2007 9:09 PM > To: [email protected] > Subject: Re: [U2] RE: Cleaner Case Statement > > I think that CASE 1;Null is an old technique. If the prior conditions don't > prevail, then don't bother. Otherwise every IF statement with a THEN would > have ELSE NULL. > > BTW, using IF X = 1 ELSE GOSUB 100 is also very hard to read. Sure it > compiles but source code should be readable for the programmers who have to > visually interpet these things. EVERY IF should have an THEN as it's > predominately a positive test instead of a negative test. Then use IF X # 1 > THEN GOSUB 100. > > > ----- Original Message ----- > From: "Allen Egerton" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Wednesday, July 25, 2007 12:48 PM > Subject: [U2] RE: Cleaner Case Statement > > > > Bill Brutzman asked: > > > > > > > How can this structure be cleaned-up? > > <snip> > > > > > begin case > > > case Ans = 'A' ; gosub Check.A > > > case Ans = 'B' > > > case Ans = '2' ; gosub Check.B > > > end case > > > > > > so that the "gosub Check.B" command is not repeated. I have tried a few > > > alternatives without a victory. > > > > > > Dunno if it's cleaner, but this is how I would code it... > > > > Begin Case > > Case Ans eq "A" > > gosub Check.A: > > Case ((Ans EQ "B") OR (Ans EQ "2")) > > gosub Check.B: > > Case 1 > > * Do nothing > > End Case > > > > -- > > Allen Egerton > > aegerton at pobox dot com > > ------- > > u2-users mailing list > > [email protected] > > To unsubscribe please visit http://listserver.u2ug.org/ > ------- > u2-users mailing list > [email protected] > To unsubscribe please visit http://listserver.u2ug.org/ > ------- > u2-users mailing list > [email protected] > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
