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: <u2-users@listserver.u2ug.org> >>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: <u2-users@listserver.u2ug.org> >>>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 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/ >>>> >>>> >>>------- >>>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/ > > > > -- Geoffrey Mitchell Programmer/Analyst Home Decorator's Collection 314-684-1062 ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
