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/

Reply via email to