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: u2-users@listserver.u2ug.org 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: <u2-users@listserver.u2ug.org> 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 > 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/
