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/
