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: <u2-users@listserver.u2ug.org> >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/
