RE: [U2] Standards [was:OCONV Extraction Question - Good Practice]
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
RE: [U2] Standards [was:OCONV Extraction Question - Good Practice]
Colin Stuart, Forgive my bluntness - quit wasting time - Write your spec. That's the challenge. I agree with much of what you've each written, but unless you codify it into some document of lasting value, we're not really going to remember it past lunchtime. Charles has submitted the Barouch spec, and people have responded to it. I would sincerely value your Spec - and would take a shot at responding to it. HTH, -Baker --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Standards [was:OCONV Extraction Question - Good Practice]
[chop] IBM and RD give us programmers the same box of crayons respectively. It's up to us to draw with them. Mark Johnson That is only true if you utilize the base BASIC code statements. Each flavor has its own special functions and user exits, but they both contain the same core BASIC statements. If you emphasize using the flavor's tweaked language to write applications, then a standard MV BASIC style does not really exist in any of your code. You have a flavor-specific MV BASIC style. IF/THEN blocks and FOR/NEXT loops are BASIC standards. IFS() is not in the D3 manual, so the proceeding argument can only be valid on flavors that have IFS(). I have no clue what it does, so I can't comment further on that. I think that someone should set up a statement cross-reference guide that shows descriptions and flavor compatibility. If there already is one, I'd love to see it. Example: UV UD D3 QMReality DCOUNT Count data segments in an MV array [X] [x] [x] [x] [x] It would also be nice to see parameter syntax for each flavor, if there are differences. If they are the same syntax then a single syntax example would suffice. Glen Batchelor IT Director All-Spec Industries phone: (910) 332-0424 fax: (910) 763-5664 E-mail: [EMAIL PROTECTED] Web: http://www.all-spec.com Blog: http://blog.all-spec.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Standards [was:OCONV Extraction Question - Good Practice]
The online Help Basic has a lot of the flavor differences indicated. From: [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Subject: RE: [U2] Standards [was:OCONV Extraction Question - Good Practice] Date: Wed, 28 Nov 2007 13:19:23 -0500 [chop] IBM and RD give us programmers the same box of crayons respectively. It's up to us to draw with them. Mark Johnson That is only true if you utilize the base BASIC code statements. Each flavor has its own special functions and user exits, but they both contain the same core BASIC statements. If you emphasize using the flavor's tweaked language to write applications, then a standard MV BASIC style does not really exist in any of your code. You have a flavor-specific MV BASIC style. IF/THEN blocks and FOR/NEXT loops are BASIC standards. IFS() is not in the D3 manual, so the proceeding argument can only be valid on flavors that have IFS(). I have no clue what it does, so I can't comment further on that. I think that someone should set up a statement cross-reference guide that shows descriptions and flavor compatibility. If there already is one, I'd love to see it. Example: UV UD D3 QMReality DCOUNT Count data segments in an MV array [X] [x] [x] [x] [x] It would also be nice to see parameter syntax for each flavor, if there are differences. If they are the same syntax then a single syntax example would suffice. Glen Batchelor IT Director All-Spec Industries phone: (910) 332-0424 fax: (910) 763-5664 E-mail: [EMAIL PROTECTED] Web: http://www.all-spec.com Blog: http://blog.all-spec.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ _ Your smile counts. The more smiles you share, the more we donate. Join in. www.windowslive.com/smile?ocid=TXT_TAGLM_Wave2_oprsmilewlhmtagline --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
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
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
