To really throw the cat amongst the pigeons ... :-) I recently started using the IF ... ELSE programming style precisely *because* I found it *easier* to understand!
Depending on what X is, it can be a lot more comprehensible to write "IF X is true ELSE" Rather than "IF NOT X THEN" Especially if X is some complicated expression. I prefer to write X in whatever manner is most easily understood (and that does not include a gratuitous negate), then use THEN or ELSE as appropriate. Cheers, Wol -----Original Message----- From: SP [mailto:[EMAIL PROTECTED] Sent: 03 August 2007 09:03 To: [email protected] Subject: Re: [U2] RE: Cleaner Case Statement The code should be easy to understand. Yes. we can figure out a lot of stuff but if making the next guy to stumble over each line having to "figure it out" is not very professional. ----- Original Message ----- From: "Symeon Breen" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, August 03, 2007 7:44 AM Subject: RE: [U2] RE: Cleaner Case Statement > 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/ ------- 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/
