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: <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....
[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/
