RE: [U2] RE: Cleaner Case Statement
Guys/Gals 1. Please trim. 2. Please note that this has moved to U2-Community. Brian --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] RE: Cleaner Case Statement
My point exactly. I've probably followed behind at least 50 mv programmers with all of my clients. I can detect a style and 'bracket' them into understanding the way they think. Factor in the time frame of their coding and their limitations come out pretty quickly. As I balance my 15 clients, I am often that programmer following myself, as I cannot remember every routine I've written for someone in the last 30 years. But recognizing easy-to-read code certainly helps get me back to speed. Thanks Mark Johnson - Original Message - From: "Geoffrey Mitchell" <[EMAIL PROTECTED]> To: Sent: Friday, August 03, 2007 4:42 PM Subject: Re: [U2] RE: Cleaner Case Statement > Alright, it really gets my goat when people start tossing around "you're > not professional" nonsense. > > Early in my (10 year) programming career, I was fond of "clever" > constructs like "if x else...". As I have matured as a developer, > however, I have realized that the hallmark of good code is > maintainability, and one of the greatest keys to maintainability is > readability. The "if x else..." construct is non-standard, and it just > doesn't flow. Sure, I understand it, but I don't expect it, so it slows > down my thought process. Saying "if not(x) then..." accomplishes the > same thing in a standard, easily readable form. It is much closer to > English language expression, and more in line with most people's thought > processes. As such, it will not slow me down in the least. I will > never have to look at it twice to make sure I'm reading it right. It > will make sense the first time. Therefore, in my opinion, it is far > superior. > > Remember, you're not coding for yourself. You're coding for everyone > who has to read your code after you. > > > Symeon Breen wrote: > > >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: > >>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: u2-users@listserver.u2ug.org > >>>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: > >>>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 &
Re: [U2] RE: Cleaner Case Statement
Alright, it really gets my goat when people start tossing around "you're not professional" nonsense. Early in my (10 year) programming career, I was fond of "clever" constructs like "if x else...". As I have matured as a developer, however, I have realized that the hallmark of good code is maintainability, and one of the greatest keys to maintainability is readability. The "if x else..." construct is non-standard, and it just doesn't flow. Sure, I understand it, but I don't expect it, so it slows down my thought process. Saying "if not(x) then..." accomplishes the same thing in a standard, easily readable form. It is much closer to English language expression, and more in line with most people's thought processes. As such, it will not slow me down in the least. I will never have to look at it twice to make sure I'm reading it right. It will make sense the first time. Therefore, in my opinion, it is far superior. Remember, you're not coding for yourself. You're coding for everyone who has to read your code after you. Symeon Breen wrote: >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: >>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: u2-users@listserver.u2ug.org >>>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: >>>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 CAS
Re: [U2] RE: Cleaner Case Statement
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: > 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: u2-users@listserver.u2ug.org > > 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: > > 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
RE: [U2] RE: Cleaner Case Statement
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: u2-users@listserver.u2ug.org 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: 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: u2-users@listserver.u2ug.org > 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: > 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.
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: 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: u2-users@listserver.u2ug.org 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: 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: u2
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: u2-users@listserver.u2ug.org 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: 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: u2-users@listserver.u2ug.org > Subject: Re: [U2] RE: Cleaner Case Statement >
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: 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: 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
Re: [U2] RE: Cleaner Case Statement
Where is said 'structured programming school' and is attendance required. Never heard of it. Thanks Mark Johnson - Original Message - From: "Allen E. Elwood" <[EMAIL PROTECTED]> To: Sent: Monday, July 30, 2007 8:35 PM Subject: RE: [U2] RE: Cleaner Case Statement > >Don't judge him/her to fast or hard - notice that this is THE ONLY WAY > >to write this > >according to the strucutural programming school ... > > The only way using structured programming??? huh, what? How about putting > the opens in a SUBR and then saying: > > GOSUB OPEN.FILES > IF ERROR THEN > PRINT 'STUFF WENT BOOM' > STOP > END > GOSUB MAIN PROCESSING.LOOP > STOP > > Structured, and clean. I agree with the original "idiot" remark :-) > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Ross Ferris > Sent: Monday, July 30, 2007 14:19 > To: u2-users@listserver.u2ug.org > Subject: RE: [U2] RE: Cleaner Case Statement > > > I see what you mean the indenting is off! No wonder it is hard for > you to follow!! (and no doubt you would have simply used a COPY > statement rather than writing a program?) > > Ross Ferris > Stamina Software > Visage > Better by Design! > > >-Original Message- > >From: [EMAIL PROTECTED] [mailto:owner-u2- > >[EMAIL PROTECTED] On Behalf Of Mats Carlid > >Sent: Monday, 30 July 2007 7:47 PM > >To: u2-users@listserver.u2ug.org > >Subject: Re: [U2] RE: Cleaner Case Statement > > > >MAJ Programming skrev: > >> ... > >> > > > >> I've inherited code from an idiot programmer that looks like this: > >> > >> OPEN FILE1 TO F1 THEN > >> OPEN FILE2 TO F2 THEN > >> OPEN FILE3 TO F3 THEN > >> LOOP WHILE READNEXT ID DO > >> READ REC FROM F1, ID THEN > >> WRITE REC ON F2, ID > >> WRITE REC ON F3, ID > >> END > >> REPEAT > >> END ELSE > >> CANNOT OPEN FILE3 > >>END ELSE > >> CANNOT OPEN FILE2 > >> END ELSE > >> CANNOT OPEN FILE1 > >> END > >> > >> C'mon. Just because something can be done differently doesn't mean > >it's > >> worth a hill of beans. > >> > >> > > > > > > > >Don't judge him/her to fast or hard - notice that this is THE ONLY WAY > >to write this > >according to the strucutural programming school ... > > > >-- mats > >--- > >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/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] RE: Cleaner Case Statement
I should preface all of my examples as examples and not be open for programming changes. The fact that it could be a COPY process is not the point. It was used to illustrate the stupid OPEN/THEN combos that I run into. Thanks Mark Johnson - Original Message - From: "Ross Ferris" <[EMAIL PROTECTED]> To: Sent: Monday, July 30, 2007 5:19 PM Subject: RE: [U2] RE: Cleaner Case Statement > I see what you mean the indenting is off! No wonder it is hard for > you to follow!! (and no doubt you would have simply used a COPY > statement rather than writing a program?) > > Ross Ferris > Stamina Software > Visage > Better by Design! > > >-Original Message- > >From: [EMAIL PROTECTED] [mailto:owner-u2- > >[EMAIL PROTECTED] On Behalf Of Mats Carlid > >Sent: Monday, 30 July 2007 7:47 PM > >To: u2-users@listserver.u2ug.org > >Subject: Re: [U2] RE: Cleaner Case Statement > > > >MAJ Programming skrev: > >> ... > >> > > > >> I've inherited code from an idiot programmer that looks like this: > >> > >> OPEN FILE1 TO F1 THEN > >> OPEN FILE2 TO F2 THEN > >> OPEN FILE3 TO F3 THEN > >> LOOP WHILE READNEXT ID DO > >> READ REC FROM F1, ID THEN > >> WRITE REC ON F2, ID > >> WRITE REC ON F3, ID > >> END > >> REPEAT > >> END ELSE > >> CANNOT OPEN FILE3 > >>END ELSE > >> CANNOT OPEN FILE2 > >> END ELSE > >> CANNOT OPEN FILE1 > >> END > >> > >> C'mon. Just because something can be done differently doesn't mean > >it's > >> worth a hill of beans. > >> > >> > > > > > > > >Don't judge him/her to fast or hard - notice that this is THE ONLY WAY > >to write this > >according to the strucutural programming school ... > > > >-- mats > >--- > >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/
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: 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: Sent: Wednesday, July 25, 2007 12:48 PM Subject: [U2] RE: Cleaner Case Statement > Bill Brutzman asked: > > > > How can this structure be cleaned-up? > > > > 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-
RE: [U2] RE: Cleaner Case Statement
Better still have a generic subroutine for all your file operations - that way the file can be xml, sql, u2, csv , etc the generic routine handles all that and you just open/read/write etc in your code in ignorant bliss - or is that too much like a framework ? Rgds Symeon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Allen E. Elwood Sent: 31 July 2007 01:35 To: u2-users@listserver.u2ug.org Subject: RE: [U2] RE: Cleaner Case Statement >Don't judge him/her to fast or hard - notice that this is THE ONLY WAY >to write this >according to the strucutural programming school ... The only way using structured programming??? huh, what? How about putting the opens in a SUBR and then saying: GOSUB OPEN.FILES IF ERROR THEN PRINT 'STUFF WENT BOOM' STOP END GOSUB MAIN PROCESSING.LOOP STOP Structured, and clean. I agree with the original "idiot" remark :-) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ross Ferris Sent: Monday, July 30, 2007 14:19 To: u2-users@listserver.u2ug.org Subject: RE: [U2] RE: Cleaner Case Statement I see what you mean the indenting is off! No wonder it is hard for you to follow!! (and no doubt you would have simply used a COPY statement rather than writing a program?) Ross Ferris Stamina Software Visage > Better by Design! >-Original Message- >From: [EMAIL PROTECTED] [mailto:owner-u2- >[EMAIL PROTECTED] On Behalf Of Mats Carlid >Sent: Monday, 30 July 2007 7:47 PM >To: u2-users@listserver.u2ug.org >Subject: Re: [U2] RE: Cleaner Case Statement > >MAJ Programming skrev: >> ... >> > >> I've inherited code from an idiot programmer that looks like this: >> >> OPEN FILE1 TO F1 THEN >> OPEN FILE2 TO F2 THEN >> OPEN FILE3 TO F3 THEN >> LOOP WHILE READNEXT ID DO >> READ REC FROM F1, ID THEN >> WRITE REC ON F2, ID >> WRITE REC ON F3, ID >> END >> REPEAT >> END ELSE >> CANNOT OPEN FILE3 >>END ELSE >> CANNOT OPEN FILE2 >> END ELSE >> CANNOT OPEN FILE1 >> END >> >> C'mon. Just because something can be done differently doesn't mean >it's >> worth a hill of beans. >> >> > > > >Don't judge him/her to fast or hard - notice that this is THE ONLY WAY >to write this >according to the strucutural programming school ... > >-- mats >--- >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/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] RE: Cleaner Case Statement
>Don't judge him/her to fast or hard - notice that this is THE ONLY WAY >to write this >according to the strucutural programming school ... The only way using structured programming??? huh, what? How about putting the opens in a SUBR and then saying: GOSUB OPEN.FILES IF ERROR THEN PRINT 'STUFF WENT BOOM' STOP END GOSUB MAIN PROCESSING.LOOP STOP Structured, and clean. I agree with the original "idiot" remark :-) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ross Ferris Sent: Monday, July 30, 2007 14:19 To: u2-users@listserver.u2ug.org Subject: RE: [U2] RE: Cleaner Case Statement I see what you mean the indenting is off! No wonder it is hard for you to follow!! (and no doubt you would have simply used a COPY statement rather than writing a program?) Ross Ferris Stamina Software Visage > Better by Design! >-Original Message- >From: [EMAIL PROTECTED] [mailto:owner-u2- >[EMAIL PROTECTED] On Behalf Of Mats Carlid >Sent: Monday, 30 July 2007 7:47 PM >To: u2-users@listserver.u2ug.org >Subject: Re: [U2] RE: Cleaner Case Statement > >MAJ Programming skrev: >> ... >> > >> I've inherited code from an idiot programmer that looks like this: >> >> OPEN FILE1 TO F1 THEN >> OPEN FILE2 TO F2 THEN >> OPEN FILE3 TO F3 THEN >> LOOP WHILE READNEXT ID DO >> READ REC FROM F1, ID THEN >> WRITE REC ON F2, ID >> WRITE REC ON F3, ID >> END >> REPEAT >> END ELSE >> CANNOT OPEN FILE3 >>END ELSE >> CANNOT OPEN FILE2 >> END ELSE >> CANNOT OPEN FILE1 >> END >> >> C'mon. Just because something can be done differently doesn't mean >it's >> worth a hill of beans. >> >> > > > >Don't judge him/her to fast or hard - notice that this is THE ONLY WAY >to write this >according to the strucutural programming school ... > >-- mats >--- >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/
RE: [U2] RE: Cleaner Case Statement
I see what you mean the indenting is off! No wonder it is hard for you to follow!! (and no doubt you would have simply used a COPY statement rather than writing a program?) Ross Ferris Stamina Software Visage > Better by Design! >-Original Message- >From: [EMAIL PROTECTED] [mailto:owner-u2- >[EMAIL PROTECTED] On Behalf Of Mats Carlid >Sent: Monday, 30 July 2007 7:47 PM >To: u2-users@listserver.u2ug.org >Subject: Re: [U2] RE: Cleaner Case Statement > >MAJ Programming skrev: >> ... >> > >> I've inherited code from an idiot programmer that looks like this: >> >> OPEN FILE1 TO F1 THEN >> OPEN FILE2 TO F2 THEN >> OPEN FILE3 TO F3 THEN >> LOOP WHILE READNEXT ID DO >> READ REC FROM F1, ID THEN >> WRITE REC ON F2, ID >> WRITE REC ON F3, ID >> END >> REPEAT >> END ELSE >> CANNOT OPEN FILE3 >>END ELSE >> CANNOT OPEN FILE2 >> END ELSE >> CANNOT OPEN FILE1 >> END >> >> C'mon. Just because something can be done differently doesn't mean >it's >> worth a hill of beans. >> >> > > > >Don't judge him/her to fast or hard - notice that this is THE ONLY WAY >to write this >according to the strucutural programming school ... > >-- mats >--- >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/
Re: [U2] RE: Cleaner Case Statement
MAJ Programming skrev: ... I've inherited code from an idiot programmer that looks like this: OPEN FILE1 TO F1 THEN OPEN FILE2 TO F2 THEN OPEN FILE3 TO F3 THEN LOOP WHILE READNEXT ID DO READ REC FROM F1, ID THEN WRITE REC ON F2, ID WRITE REC ON F3, ID END REPEAT END ELSE CANNOT OPEN FILE3 END ELSE CANNOT OPEN FILE2 END ELSE CANNOT OPEN FILE1 END C'mon. Just because something can be done differently doesn't mean it's worth a hill of beans. Don't judge him/her to fast or hard - notice that this is THE ONLY WAY to write this according to the strucutural programming school ... -- mats --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] RE: Cleaner Case Statement
I'm not saying banned. I'm saying that there's a popular leaning for the logic statements and their predominant outcomes. IF happens to be THEN and READ and OPEN happen to be ELSE. In early days, IF only had THEN and ELSE was added later. READ and OPEN only had ELSE and THEN was added later. So IF X=1 ELSE is just someone's overly deviating way of confusing the next reader. Why not use IF X # 1 THEN as it's the same thing. As I scan a program, I see IF X = 1 and assume it should be a THEN. (no flames on assumptions). If you review decades of code both old and new as I have, you'll see that IF runs 99% THEN and OPEN runs 99% ELSE. The 1% opposite is just causing trouble. The READ does have a higher degree of using the THEN clause but in the example below, I tend to like READ REC FROM F1, ID ELSE CONTINUE and saving one indent set and the END line. I've inherited code from an idiot programmer that looks like this: OPEN FILE1 TO F1 THEN OPEN FILE2 TO F2 THEN OPEN FILE3 TO F3 THEN LOOP WHILE READNEXT ID DO READ REC FROM F1, ID THEN WRITE REC ON F2, ID WRITE REC ON F3, ID END REPEAT END ELSE CANNOT OPEN FILE3 END ELSE CANNOT OPEN FILE2 END ELSE CANNOT OPEN FILE1 END C'mon. Just because something can be done differently doesn't mean it's worth a hill of beans. My 3 cents. - Original Message - From: "Scott Ballinger" <[EMAIL PROTECTED]> To: Sent: Saturday, July 28, 2007 2:10 AM Subject: Re: [U2] RE: Cleaner Case Statement > On 7/27/07, MAJ Programming <[EMAIL PROTECTED]> wrote: > > > > [snip] > > 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. > > > > By that logic READ REC FROM FILE,ID ELSE ... should be banned as well? > I think we are all pretty well conditioned to not be confused by the lack of > the THEN clause in this case. I suspect it is mostly what you are used to, > and I think you can get used to quite a lot. Sometimes adding extra words to > make code more "readable" has just the opposite effect. It's all really just > personal preferences, but it feels more professional to call them > "standards." > > my 0.02... > /Scott Ballinger > Pareto Corporation > Edmonds WA USA > 206 713 6006 > --- > 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/
Re: [U2] RE: Cleaner Case Statement
Please don't rule that READ REC is the same as IF THEN. The whole premise of an IF statement is predominately looking for the positive test. While many can argue, it's no way a 50/50 split between the IF being true and the IF being false. The majority usage happens to be the positive, ie the THEN. So when I'm reading through code my brain is acclimated to reading IF X = 1 blah, blah, blah assuming the conditions are aiming towards True (THEN). When I come across an IF X = 1 ELSE statement it's so out of the ordinary that it looks out of place. Is it wrong and illogical? No, But it's not that welcome when it could have easily been IF X # 1 THEN. Period. There are thousands of IF X # 1 THEN examples as compared to IF X = 1 ELSE. Years ago the earlier forms of IF did not have an ELSE so you had to program around it. I'm not stuck there. It's just a good foundation to consider IF statements leaning towards the positive. The THEN in READ REC wasn't there in the beginning of MV either. There was the mental conditioning that you kinda assumed that it was going to be there and had to handle the exception differently (ELSE). Even OPEN didn't have a THEN then as it was a failure oriented command like READ. THEN came later. I'm not saying any is better or not. But if you review decades of code, both new and old, you'll see that the predominance of IF is THEN and READ and OPEN is ELSE. You can look that up. - Original Message - From: "Scott Ballinger" <[EMAIL PROTECTED]> To: Sent: Saturday, July 28, 2007 2:10 AM Subject: Re: [U2] RE: Cleaner Case Statement > On 7/27/07, MAJ Programming <[EMAIL PROTECTED]> wrote: > > > > [snip] > > 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. > > > > By that logic READ REC FROM FILE,ID ELSE ... should be banned as well? > I think we are all pretty well conditioned to not be confused by the lack of > the THEN clause in this case. I suspect it is mostly what you are used to, > and I think you can get used to quite a lot. Sometimes adding extra words to > make code more "readable" has just the opposite effect. It's all really just > personal preferences, but it feels more professional to call them > "standards." > > my 0.02... > /Scott Ballinger > Pareto Corporation > Edmonds WA USA > 206 713 6006 > --- > 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/
Re: [U2] RE: Cleaner Case Statement
On 7/27/07, MAJ Programming <[EMAIL PROTECTED]> wrote: > > [snip] > 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. > By that logic READ REC FROM FILE,ID ELSE ... should be banned as well? I think we are all pretty well conditioned to not be confused by the lack of the THEN clause in this case. I suspect it is mostly what you are used to, and I think you can get used to quite a lot. Sometimes adding extra words to make code more "readable" has just the opposite effect. It's all really just personal preferences, but it feels more professional to call them "standards." my 0.02... /Scott Ballinger Pareto Corporation Edmonds WA USA 206 713 6006 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
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: Sent: Wednesday, July 25, 2007 12:48 PM Subject: [U2] RE: Cleaner Case Statement > Bill Brutzman asked: > > > > How can this structure be cleaned-up? > > > > 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] RE: Cleaner Case Statement
Bill Brutzman asked: How can this structure be cleaned-up? 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/
