personaly i find 'if x else' or if y then else just as easy to understand. if you stumble over such simple constructs then you are not a professional . sorry if that sound harsh, but it is my 2pennies...
rgds Symeon On 03/08/07, SP <[EMAIL PROTECTED]> wrote: > 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/
