Re: [U2] OCONV Extraction Question - Best Practises
I am living that mess of the 'future maintainer' right now. I've inherited 2 systems due to the prior programmer leaving town and while that programmer was very smart and had a good memory for the 10+ years of code he wrote, he barely commented anything, has ambiguous program and file names and, due to working 80% with The Programmer's Helper, everything is inconsistently abbreviated. So I figure that 10-15% of what I'm typing is not code but comments. I put comments in programs declaring why I am reviewing it in the first place and what it's attached to. I have a DICT README record in every data file for its nominal purpose and other commentary. I wrote a FIND.ALL program to review every BP file, Proc and MD in these multi-account systems to see if program FIX.RECORD-3 is used anywhere or a one-shot 'programmer's program. I have programs that sniff out OPEN attempted files that STOP upon failure to consider archiving the program out of the mainline BP files. All of this exposure of bad techiques will help many people develop their own Best Practices. MJ - Original Message - From: "Kevin King" <[EMAIL PROTECTED]> To: Sent: Monday, November 19, 2007 1:17 PM Subject: Re: [U2] OCONV Extraction Question - Best Practises > In response to Susan's mention of the criteria for evaluating code, I > submit that I personally verify code against three criteria: > > 1) Is it accurate? Does it fulfill its designed mission? Often times > code misses this mark simply because of the shifting sands of > requirements, and what might have been accurate six months ago may no > longer be so. > > 2) Does it perform as well as it could? This is where the multiple > READV/WRITEV thing falls down, as it may not be the most efficient way > of achieving a given objective. > > 3) Is it maintainable? This goes far beyond "readable" to include > elements to strengthen comprehension of the context and intended > objective and how the source code interprets the implementation of > that objective. This includes standardized code fragments and > structures, predictable and consistent variable naming conventions, > intentional use and avoidance of certain language elements (such as GE > verses >= for comparison) and commenting styles and standards. > > Too often, as Susan has pointed out, programmers write code to make > today's problem go away because there are a dozen or more projects > lined up behind it, instead of writing the code thinking of the guy > who will be reading the code several months from now. I submit that > we should always keep the future maintainer in mind, assuming that > they know nothing of the context, little of the problem, and less time > than needed to achieve their objective. If we don't set the stage for > that person's success, we shouldn't be surprised when they don't > describe our work in the most complimentary of terms. > --- > 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] OCONV Extraction Question - Best Practises
I'm all for exposing my personal techniques and watching the flames come. Granted, there will be some holy wars but in the end, many ambiguous conditions may be solved one way or another. I have exposed my personal techniques for many years on these forums and will defend them as I understand the offenders. I am also smart enough to change a technique if I see a better one. It doesn't have to be voted unanimously to be my favorite. We all can tell what techniques will fit comfortably with our existing skills. I, for one, do not care for the EQU CUST.NAME to CUSTOMER(1) style of coding. I do not like using attr 99 for calculated dictionary items (sorry, that's another forum). I have my own preferred way of opening files, file handle names, and even constructively mixing numeric with alphabetic labels. While there will be no winners, everyone will be a winner as we all will become exposed to other techniques that many of us may not have had the luxury of reviewing many different systems. I can't wait. Mark Johnson PS. Hopefully this doesn't become an artistic expression of grandeur. Meaning, if the chapter was the best way to multiply 2 numbers together, A=B*C must win. If someone submits A=e^(ln(B)+ln(C)) then that misses the point. - Original Message - From: "Kevin King" <[EMAIL PROTECTED]> To: Sent: Monday, November 19, 2007 12:07 PM Subject: Re: [U2] OCONV Extraction Question - Best Practises > I'd play on that field, Chuck. Not looking for a flame war, but I > know there are a lot of people with some great ideas and there's much > to be gained by keeping the lines of communication open. Then again, > topics like alpha vs. numeric labels could turn out to be massively > polarizing. > --- > 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] OCONV Extraction Question - Best Practises
I would be in favor of chapterizing the various coding concepts into a greatest hits collection. As I have transversed perhaps 35 different MV systems during my career, I have had the chance to view many practices, both good and bad. I add the good ones to my collection (always willing to learn) and scratch my head at some of the crazy ones. I do give the benefit of the doubt in some cases as I can 'age' the programs and personally recall the available thought processes at the time. But also having been around since almost the beginning, I can see when some commands were used when the better ones were certainly available. Thus, those fall into the 'bad' category. Example of a bad technique that has no reason for its use: WHOLE.NAME="MARK JOHNSON" II=INDEX(WHOLE.NAME," ",1) FIRST.NAME=WHOLE.NAME[1,II-1] ain't that called the FIELD command. Things like that. My 2 cents Mark Johnson - Original Message - From: "Baker Hughes" <[EMAIL PROTECTED]> To: Sent: Monday, November 19, 2007 10:17 AM Subject: RE: [U2] OCONV Extraction Question - Best Practises > It's JUST a preference, presently > > I know we all reach for a good balance between brevity and clarity. > > I have some preferences too which I think are ideal, which seem less > than ideal to others. > > ... but rather than mount my own hobby horse I have a suggestion / > question that could put these types of exchanges to rest: > > WHAT IF - the U2UG took it as a future project to compile a Best > Practices coding guideline document for our language? > > There's always helpful 'How to' stuff exchanged here. ...but style > question sometimes spiral downward. > > As someone pointed out recently, we have the blessing and curse of using > a rather free style language. > Not much Structure-Style is not imposed by the construct of the language > itself, like some others. > > Is it time to codify some best practices relating to structure, > modularity, reuse, length of internal subs, etc? > > I may not like some of the resulting definitions myself but it would > build cohesion and greater respect for the MV space. > Another thing it would do is chart a clearer path for those coming > behind us - we need new blood if the VARs in this space are going to > continue to sell/support embedded MV apps. > > I would personally find it fascinating to see some of our venerable > coders get together and see what they produced along this line. I have > some names in mind but I'll wait for the nominations to officially open. > > Happy Thanksgiving. > > -Baker > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming > Sent: Saturday, November 17, 2007 12:58 AM > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] OCONV Extraction Question > > According to who? > > I know there are some pluses and minuses but where is this decided or is > it just a preference. > > Thanks > Mark Johnson > - Original Message - > From: "Brutzman, Bill" <[EMAIL PROTECTED]> > To: > Sent: Friday, November 16, 2007 11:30 AM > Subject: RE: [U2] OCONV Extraction Question > > > > Speaking of mis-used commands and side-stepping some of the given code > > > craziness... > > > > It is better practice to atomize the code into discrete elements such > as... > > > > Var1.F = oconv(Var1, 'MD0') > > crt Var1.F 'R#11' > > > > rather than to try to kill two birds with one stone by including an > > oconv statement inside a crt statement such as... > > > > crt oconv(Var1, 'MD0') > > > > --Bill > > > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of MAJ > > Programming > > Sent: Friday, November 16, 2007 12:48 AM > > To: u2-users@listserver.u2ug.org > > Subject: Re: [U2] OCONV Extraction Question > > > > > > This is real smart, making things harder than they should be. Just use > <>. > > > > Mark Johnson > > - Original Message - > > From: <[EMAIL PROTECTED]> > > To: > > Sent: Wednesday, November 14, 2007 5:23 PM > > Subject: RE: [U2] OCONV Extraction Question > > > > > > > Didn't work for me either. It may not fit what you need, but SWAP > > > can > make > > > it work. > > > > > > VAR1 = 'SAM':@VM:'TRUDY' > > > SWAP @VM WITH '*' IN VAR1 > > > FMTSTR = 'G*1' > > > CRT OCONV(VAR1,FMTSTR) > > > > > > Bra
Re: [U2] OCONV Extraction Question - Best Practises
Charles: GREAT point! In the overarching scheme of things, we should never forget that while original implementation has a fixed timeline, maintenance can be forever. More importantly, the costs of each are commensurate with its lifetime. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] OCONV Extraction Question - Best Practises
Great discussion! One thing that I have learned in my 25 years in IT is that early on, I underestimated the importance of maintainability. I noticed this when I got into management. I had a programmer who seemed to be slow, but when you looked at her code, it was BEAUTIFUL. Anyone could easily modify her code because she made the intent SO obvious through structure and comments. The time saved working with her code FAR outweighed the extra time she took coding it. Charles Shaffer Senior Analyst NTN-Bower Corporation --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] OCONV Extraction Question - Best Practises
Susan,
All of which makes the determination of "best practices" rather
difficult, since it depends on the criteria you choose for the
evaluation - efficiency? Ease of maintenance? Conformation to 'site
standards'? Ability to call a logical module from multiple locations in
the wider application? Auditability of the results? Various standards
of presentation of data for the user interface? Once you get beyond the
very simple aspects of programming, everything has to be judged in the
context of the application as a whole, rather than on the brilliance (or
lack thereof) of small code fragments.
Susan Lynch
If there were a set of best practices, no one would expect old code to
conform to it, only new or re-factored code.
Obviously, if you are working with 20 year old code, as many of us are,
you have a huge limitation out of the box (unless you have unlimited
freedom to re-write your app [and multiply QA time exponentially]). The
purpose of any 'best practices' document{s) would be to set forth ideal
methodologies. It is up to the art and skill of the individual
programmer to incorporate those methodologies, insofar as s/he can, into
their every project.
However, well formed, well structured, modular code will satisfy all the
evaluation points you mentioned. The one sticky point could be 'site
standards' - but hopefully those sites that have arcane 'standards'
would consider the weight and authority of a 'industry recognized' [De
Facto] standard 'best practices' document, and change their archaic
ways.
just my .002
-Baker
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] OCONV Extraction Question - Best Practises
Susan: See. This brings up the difference between coding styles and guidelines. The guidline is: If you use it once use it once. If you use it twice either create a variable or a local subroutine. If it's used in more than one program then either create a common variable or a separate subroutine. You get the idea. Now we expose ourselves to style. Style 1: OfficeRec(5) = OfficeRec(6) * OfficeRec(7) Style 2: EQUATE OfficeSize to OfficeRec(4) OfficeWidth = OfficeRec(6) OfficeDepth = OfficeRec(7) OfficeSize = OfficeWidth * OfficeDepth I think this demonstrates the style differences between brevity and clarity. Style 1 accomplishes exactly what's needed while style 2 reflects the need for clarity of what's actually being done. Often I simply add a comment to Style 1 like: Style 1 (amended): OfficeRec(5) = OfficeRec(6) * OfficeRec(7) ; ** the size of the office in square footage However, as you say, if I'm using any of the variables elsewhere in the code, or was referencing a dynamic instead of a dimensioned array for OfficeRec, I'd much prefer Style 2. So it seems to me there really is a difference between style and guidelines. :-) Bill >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Susan Lynch >Sent: Monday, November 19, 2007 9:25 AM >To: u2-users@listserver.u2ug.org >Subject: Re: [U2] OCONV Extraction Question - Best Practises > >Actually, that brings up an important point - my preference would be that >if you are going to do it once and never re-use that value, then it probably >makes sense to do it in one line, and not add the additional variable, but >if you are going to need it again, as the OCONV'd value, it makes sense to >set a new variable to the OCONV'd value and use the variable, rather than >re-doing the oconv. [snipped] >Susan Lynch > >- Original Message - >From: "Anthony Youngman" <[EMAIL PROTECTED]> >To: >Sent: Monday, November 19, 2007 11:19 AM >Subject: RE: [U2] OCONV Extraction Question - Best Practises > > >> Just DON'T start a few flame wars over this :-) >> >> I'd actually vehemently disagree with the original suggestion, for several >> reasons. The two biggest are: >> >> It introduces an extra variable. Any poor maintenance guy coming along has >> to worry about whether it's used elsewhere. This sort of behaviour is >> actually frowned on in ANY programming language, I believe. >> >> And my personal reason for disliking it, over and above the previous - it >> takes two lines where one would do. Okay, compressing code for the sake of >> it can hinder comprehension, but I like tight, compact code with >> white-space separating small sections, not individual sections full of >> white space... >> >> Cheers, >> Wol >> >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Baker Hughes >> Sent: 19 November 2007 15:18 >> To: u2-users@listserver.u2ug.org >> Subject: RE: [U2] OCONV Extraction Question - Best Practises >> >> It's JUST a preference, presently [snipped] >>> Speaking of mis-used commands and side-stepping some of the given code >>> >>> craziness... >>> >>> It is better practice to atomize the code into discrete elements such >>> as... >>> >>> Var1.F = oconv(Var1, 'MD0') >>> crt Var1.F 'R#11' >>> >>> rather than to try to kill two birds with one stone by including an >>> oconv statement inside a crt statement such as... >>> >>> crt oconv(Var1, 'MD0') >>> >>> --Bill> --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] OCONV Extraction Question - Best Practises
In response to Susan's mention of the criteria for evaluating code, I submit that I personally verify code against three criteria: 1) Is it accurate? Does it fulfill its designed mission? Often times code misses this mark simply because of the shifting sands of requirements, and what might have been accurate six months ago may no longer be so. 2) Does it perform as well as it could? This is where the multiple READV/WRITEV thing falls down, as it may not be the most efficient way of achieving a given objective. 3) Is it maintainable? This goes far beyond "readable" to include elements to strengthen comprehension of the context and intended objective and how the source code interprets the implementation of that objective. This includes standardized code fragments and structures, predictable and consistent variable naming conventions, intentional use and avoidance of certain language elements (such as GE verses >= for comparison) and commenting styles and standards. Too often, as Susan has pointed out, programmers write code to make today's problem go away because there are a dozen or more projects lined up behind it, instead of writing the code thinking of the guy who will be reading the code several months from now. I submit that we should always keep the future maintainer in mind, assuming that they know nothing of the context, little of the problem, and less time than needed to achieve their objective. If we don't set the stage for that person's success, we shouldn't be surprised when they don't describe our work in the most complimentary of terms. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] OCONV Extraction Question - Best Practises
My personal preference is to atomize. This goes back to my C days. I found that while it was possible to cram a lot of code into one line, there were portability problems. The same code could compile differently on different platforms depending on how the C compiler handled the complex lines. I don't know if there are similar issues with UniBasic, or not. Also, I personally find the atomized code easier to read and more explicit. Charles Shaffer Senior Analyst NTN-Bower Corporation >Just DON'T start a few flame wars over this :-) >I'd actually vehemently disagree with the original suggestion, for several reasons. The two biggest are: >It introduces an extra variable. Any poor maintenance guy coming along has to worry about whether it's used elsewhere. This sort of behaviour is >actually frowned on in ANY programming language, I believe. >And my personal reason for disliking it, over and above the previous - it takes two lines where one would do. Okay, compressing code for the sake of >it can hinder comprehension, but I like tight, compact code with white-space separating small sections, not individual sections full of white >space... >Cheers, >Wol > Speaking of mis-used commands and side-stepping some of the given code > craziness... > > It is better practice to atomize the code into discrete elements such as... > > Var1.F = oconv(Var1, 'MD0') > crt Var1.F 'R#11' > > rather than to try to kill two birds with one stone by including an > oconv statement inside a crt statement such as... > > crt oconv(Var1, 'MD0') > > --Bill --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] OCONV Extraction Question - Best Practises
I'd play on that field, Chuck. Not looking for a flame war, but I know there are a lot of people with some great ideas and there's much to be gained by keeping the lines of communication open. Then again, topics like alpha vs. numeric labels could turn out to be massively polarizing. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] OCONV Extraction Question - Best Practises
Actually, that brings up an important point - my preference would be that if you are going to do it once and never re-use that value, then it probably makes sense to do it in one line, and not add the additional variable, but if you are going to need it again, as the OCONV'd value, it makes sense to set a new variable to the OCONV'd value and use the variable, rather than re-doing the oconv. But that requires that a maintenance programmer take the time to know the program rather than look at the surrounding 20 lines or so (and their performance is probably evaluated on how fast they get the changes made rather than on their effect on the quality of the code), which is why most of us have so often seen (particularly in programs generated by a code-generator or in programs maintained by a variety of people over many years) multiple READV's and WRITEV's rather than a single read of the record, or multiple OCONV's of the exact same field with the exact same masking. But making the decision based on the need is my personal preference - others may prefer a standardized approach for ease of training new programmers or may argue that "disk is cheap, memory is cheap" and prefer not to focus on efficiency as one of the criteria for evaluating code. All of which makes the determination of "best practices" rather difficult, since it depends on the criteria you choose for the evaluation - efficiency? Ease of maintenance? Conformation to 'site standards'? Ability to call a logical module from multiple locations in the wider application? Auditability of the results? Various standards of presentation of data for the user interface? Once you get beyond the very simple aspects of programming, everything has to be judged in the context of the application as a whole, rather than on the brilliance (or lack thereof) of small code fragments. Susan Lynch - Original Message - From: "Anthony Youngman" <[EMAIL PROTECTED]> To: Sent: Monday, November 19, 2007 11:19 AM Subject: RE: [U2] OCONV Extraction Question - Best Practises Just DON'T start a few flame wars over this :-) I'd actually vehemently disagree with the original suggestion, for several reasons. The two biggest are: It introduces an extra variable. Any poor maintenance guy coming along has to worry about whether it's used elsewhere. This sort of behaviour is actually frowned on in ANY programming language, I believe. And my personal reason for disliking it, over and above the previous - it takes two lines where one would do. Okay, compressing code for the sake of it can hinder comprehension, but I like tight, compact code with white-space separating small sections, not individual sections full of white space... Cheers, Wol -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Baker Hughes Sent: 19 November 2007 15:18 To: u2-users@listserver.u2ug.org Subject: RE: [U2] OCONV Extraction Question - Best Practises It's JUST a preference, presently [SNIP] [END SNIP] Speaking of mis-used commands and side-stepping some of the given code craziness... It is better practice to atomize the code into discrete elements such as... Var1.F = oconv(Var1, 'MD0') crt Var1.F 'R#11' rather than to try to kill two birds with one stone by including an oconv statement inside a crt statement such as... crt oconv(Var1, 'MD0') --Bill> --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] OCONV Extraction Question - Best Practises
Just DON'T start a few flame wars over this :-) I'd actually vehemently disagree with the original suggestion, for several reasons. The two biggest are: It introduces an extra variable. Any poor maintenance guy coming along has to worry about whether it's used elsewhere. This sort of behaviour is actually frowned on in ANY programming language, I believe. And my personal reason for disliking it, over and above the previous - it takes two lines where one would do. Okay, compressing code for the sake of it can hinder comprehension, but I like tight, compact code with white-space separating small sections, not individual sections full of white space... Cheers, Wol -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Baker Hughes Sent: 19 November 2007 15:18 To: u2-users@listserver.u2ug.org Subject: RE: [U2] OCONV Extraction Question - Best Practises It's JUST a preference, presently I know we all reach for a good balance between brevity and clarity. I have some preferences too which I think are ideal, which seem less than ideal to others. ... but rather than mount my own hobby horse I have a suggestion / question that could put these types of exchanges to rest: WHAT IF - the U2UG took it as a future project to compile a Best Practices coding guideline document for our language? There's always helpful 'How to' stuff exchanged here. ...but style question sometimes spiral downward. As someone pointed out recently, we have the blessing and curse of using a rather free style language. Not much Structure-Style is not imposed by the construct of the language itself, like some others. Is it time to codify some best practices relating to structure, modularity, reuse, length of internal subs, etc? I may not like some of the resulting definitions myself but it would build cohesion and greater respect for the MV space. Another thing it would do is chart a clearer path for those coming behind us - we need new blood if the VARs in this space are going to continue to sell/support embedded MV apps. I would personally find it fascinating to see some of our venerable coders get together and see what they produced along this line. I have some names in mind but I'll wait for the nominations to officially open. Happy Thanksgiving. -Baker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming Sent: Saturday, November 17, 2007 12:58 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] OCONV Extraction Question According to who? I know there are some pluses and minuses but where is this decided or is it just a preference. Thanks Mark Johnson - Original Message - From: "Brutzman, Bill" <[EMAIL PROTECTED]> To: Sent: Friday, November 16, 2007 11:30 AM Subject: RE: [U2] OCONV Extraction Question > Speaking of mis-used commands and side-stepping some of the given code > craziness... > > It is better practice to atomize the code into discrete elements such as... > > Var1.F = oconv(Var1, 'MD0') > crt Var1.F 'R#11' > > rather than to try to kill two birds with one stone by including an > oconv statement inside a crt statement such as... > > crt oconv(Var1, 'MD0') > > --Bill > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of MAJ > Programming > Sent: Friday, November 16, 2007 12:48 AM > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] OCONV Extraction Question > > > This is real smart, making things harder than they should be. Just use <>. > > Mark Johnson > - Original Message - > From: <[EMAIL PROTECTED]> > To: > Sent: Wednesday, November 14, 2007 5:23 PM > Subject: RE: [U2] OCONV Extraction Question > > > > Didn't work for me either. It may not fit what you need, but SWAP > > can make > > it work. > > > > VAR1 = 'SAM':@VM:'TRUDY' > > SWAP @VM WITH '*' IN VAR1 > > FMTSTR = 'G*1' > > CRT OCONV(VAR1,FMTSTR) > > > > Brad > > > > > > U.S. BANCORP made the following annotations > > > > - Electronic Privacy Notice. This e-mail, and any attachments, > > contains > information that is, or may be, covered by electronic communications privacy > laws, and is also confidential and proprietary in nature. If you are > not the > intended recipient, please be advised that you are legally prohibited > from retaining, using, copying, distributing, or otherwise disclosing > this information in any manner. Instead, please reply to the sender > that you have > received this communication in error, and then immediately delete it
Re: [U2] OCONV Extraction Question - Best Practises
Baker, I agree, but the path is hard and the way is murky. A few months back, I posted a free skeleton maker, which implemented some reasonable commenting. When I opened it up to the list for comments, the response was greatly varied. Some people even replied privately for fear of starting a flame war on the lists. If we are going to do as you suggested, I only see one way to make that work: Let's get a few people to each write up their own style guideline and subject them all to the list's opinions, with each originator having a final say on their guideline. We can post them all to U2UG.org and let people select the one they like. it won't have the value of setting a single style, but it has the value of being possible. Anyone frustrated with all choices can petition the author who is closest or they can roll their own and subject it to feedback. Anyone willing to step up? I'd be willing to play under these terms. - Chuck Baker Hughes wrote: WHAT IF - the U2UG took it as a future project to compile a Best Practices coding guideline document for our language? --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] OCONV Extraction Question - Best Practises
It's JUST a preference, presently I know we all reach for a good balance between brevity and clarity. I have some preferences too which I think are ideal, which seem less than ideal to others. ... but rather than mount my own hobby horse I have a suggestion / question that could put these types of exchanges to rest: WHAT IF - the U2UG took it as a future project to compile a Best Practices coding guideline document for our language? There's always helpful 'How to' stuff exchanged here. ...but style question sometimes spiral downward. As someone pointed out recently, we have the blessing and curse of using a rather free style language. Not much Structure-Style is not imposed by the construct of the language itself, like some others. Is it time to codify some best practices relating to structure, modularity, reuse, length of internal subs, etc? I may not like some of the resulting definitions myself but it would build cohesion and greater respect for the MV space. Another thing it would do is chart a clearer path for those coming behind us - we need new blood if the VARs in this space are going to continue to sell/support embedded MV apps. I would personally find it fascinating to see some of our venerable coders get together and see what they produced along this line. I have some names in mind but I'll wait for the nominations to officially open. Happy Thanksgiving. -Baker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming Sent: Saturday, November 17, 2007 12:58 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] OCONV Extraction Question According to who? I know there are some pluses and minuses but where is this decided or is it just a preference. Thanks Mark Johnson - Original Message - From: "Brutzman, Bill" <[EMAIL PROTECTED]> To: Sent: Friday, November 16, 2007 11:30 AM Subject: RE: [U2] OCONV Extraction Question > Speaking of mis-used commands and side-stepping some of the given code > craziness... > > It is better practice to atomize the code into discrete elements such as... > > Var1.F = oconv(Var1, 'MD0') > crt Var1.F 'R#11' > > rather than to try to kill two birds with one stone by including an > oconv statement inside a crt statement such as... > > crt oconv(Var1, 'MD0') > > --Bill > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of MAJ > Programming > Sent: Friday, November 16, 2007 12:48 AM > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] OCONV Extraction Question > > > This is real smart, making things harder than they should be. Just use <>. > > Mark Johnson > - Original Message - > From: <[EMAIL PROTECTED]> > To: > Sent: Wednesday, November 14, 2007 5:23 PM > Subject: RE: [U2] OCONV Extraction Question > > > > Didn't work for me either. It may not fit what you need, but SWAP > > can make > > it work. > > > > VAR1 = 'SAM':@VM:'TRUDY' > > SWAP @VM WITH '*' IN VAR1 > > FMTSTR = 'G*1' > > CRT OCONV(VAR1,FMTSTR) > > > > Brad > > > > > > U.S. BANCORP made the following annotations > > > > - Electronic Privacy Notice. This e-mail, and any attachments, > > contains > information that is, or may be, covered by electronic communications privacy > laws, and is also confidential and proprietary in nature. If you are > not the > intended recipient, please be advised that you are legally prohibited > from retaining, using, copying, distributing, or otherwise disclosing > this information in any manner. Instead, please reply to the sender > that you have > received this communication in error, and then immediately delete it. Thank > you in advance for your cooperation. > > > > > > > > > > - > > --- > > 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/
