Very good analogy and I agree with you.
> -----Original Message----- > From: MAJ Programming [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 28, 2007 12:06 AM > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] Standards [was:OCONV Extraction Question - Good Practice] > > Standards vs Styles. > > I think Standards are top-down delivered entities in the language from the > database providers, ie IBM, Raining Data etc. It's the syntax of commands. > > Styles are the localized adaptations of the commands, combined for a > consistency. They should not extend beyond the horizon of the programs that > the 'stylists' have control over. > > Thus, we can share 'styles' and even vote on them. But we all can choose to > pick and choose which ones we feel are better suited for use within our own > horizons. > > IBM and RD give us programmers the same box of crayons respectively. It's up > to us to draw with them. > > Mark Johnson > ----- Original Message ----- > From: "Boydell, Stuart" <[EMAIL PROTECTED]> > To: <u2-users@listserver.u2ug.org> > Sent: Tuesday, November 27, 2007 9:27 PM > Subject: RE: [U2] Standards [was:OCONV Extraction Question - Good Practice] > > > > Colin, > > excuse my top-posting - I'm using Outlook. > > > > Lol. Well it was supposed to be rhetorical and I wasn't expecting a > > response but since you have; may I cast an opinion that boiling down a > > definition of "good code" to being efficient and maintainable and > > calling it a standard is an oversimplification and well, plain > > dangerous. > > > > Of course code should try to exhibit both qualities but, as you point > > out, they're value calls and aren't measurable by themselves. Standards > > should always be concrete. Possibly like: "Always use a matching 'END' > > clause after an 'IF/THEN' construct regardless of the number of > > statements (eg no single-line IF/THEN conditionals)". It's a concrete > > rule and it can be justified because it makes code 'look' consistent and > > that's something which helps errors to stand out. It's also no less > > efficient at runtime to use IF/THEN/END than a single line IF/THEN for a > > condition with only one statement to be performed. (Whether a shop would > > actually choose that as a real standard is not the point in this > > example). > > > > Among other qualities of 'good' code, I would say - Does it also perform > > its function? Obvious to say but does code always handle potential > > errors? something which I see very little of in certain areas of > > standard pick code. This can make code quite convoluted... using > > READU/LOCKED/ON ERROR/ELSE, BEGIN/END TRANSACTION etc. Possibly > > overengineered, inefficient, even ugly. But is a program performing its > > function if say, an update gets a ledger out of balance because it > > doesn't handle a lock, or an out of sync update anomaly correctly. There > > is the real risk of costly repercussions to the business. I'm sure > > everyone has seen examples of programs that only blind luck keeps > > running in production. > > > > On the "no need to look in a manual therefore it must be maintainable" > > mantra. A hypothetical if you will: You're in a U2 only shop working on > > a testing the values of a dynamic array variable. Would you a) use a > > DCOUNT(), FOR/NEXT construct and call IF/THEN multiple times or b) use a > > single IFS() vector function? (leaving aside REMOVE() for the moment) > > can you tell me which construct you'd use measured against "efficient" > > and "maintainable"? > > > > I'd look at it in light of the "efficient" and "maintainable" standard > > and say: The single IFS() function is an order of magnitude simpler and > > quanta more efficient than the DCOUNT/FOR/IF/THEN/NEXT. In my mind > > something which is a simple, single statement is more maintainable than > > a multi line/multi statement construct. So for my money, it's a "lay > > down misere" I'd use the IFS(). > > > > However, IFS() isn't used very often in code I've seen. Do you still > > give in to your standard and use the IFS()? You could make an assumption > > about the maintenance programmer coming after you. Will they look at > > IFS(), suddenly go very pale, panic, run screaming out of the room > > crying 'heresy' and never code again? Or do you give them a smidgeon of > > credit, that though they have never seen IFS() before, they can open one > > of the dusty, paper manuals that's been propping up a shelf for the past > > 20 years and read the explanation of IFS() and work it out (Of course, > > they could then refactor it back to a FOR/IF/THEN/NEXT construct because > > they're being paid by the hour). > > > > It's a curly path and I reckon that unless you have concrete statement > > which says - "never use" or "always use" vector functions - it's a > > guideline not a standard. > > > > Cheers, > > Stuart > > > > > > >-----Original Message----- > > >> "Good" code. What (TF) is that and how does that relate to a > > statements > > >> inclusion in a manual or not? > > >> Explain yourself and - the rules for you are - don't peek in a > > >> dictionary or use an electronic grammar or spell checker. ;-) > > >> Stuart Boydell > > > > > > > > >Hi Stuart. > > > > > >Ignoring all dictionary and thesaurus explanations available I have a > > simple > > >definition of "good" code - is it efficient and can it be easily > > maintained > > >by someone else? I appreciate that this is an arbitary and difficult > > to > > >measure standard, but it's my standard nonetheless :-) > > > > > >We have a language that invariably allows a solution to be written in a > > >number of different ways. If I was to work alongside - or worse, after > > - a > > >programmer that utiilised obscure conversion codes that no-one else > > >understood rather than a simpler to read line of code that did exactly > > the > > >same thing then I wouldn't be very happy. While my original point was > > >relating to the certification questions, the post from Keith this week > > where > > >he changed the line of code into something much more readable is a > > classic > > >example. We may not all agree with precisely how he's done it, but we > > can > > >probably all see the reason why he did. > > > > > >The discussions about coding that have woken this list up in recent > > weeks > > >show that there are lots of "standards" out there, but I think that > > there is > > >probably one rule that's true to all of us - we all recognise bad code > > when > > >we see it, even if it was us what wrote it! > > > > > >Colin. > > >------- > > >u2-users mailing list > > >u2-users@listserver.u2ug.org > > >To unsubscribe please visit http://listserver.u2ug.org/ > > > > > > ********************************************************************** > > This email message and any files transmitted with it are confidential and > intended solely for the use of addressed recipient(s). If you have received > this communication in error, please reply to this e-mail to notify the > sender of its incorrect delivery and then delete it and your reply. It is > your responsibility to check this email and any attachments for viruses and > defects before opening or sending them on. Spotless collects information > about you to provide and market our services. For information about use, > disclosure and access, see our privacy policy at http://www.spotless.com.au > > Please consider our environment before printing this email. > > ********************************************************************** > > ------- > > 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/
