On 12/9/2016 3:30 PM, Michael Ryan wrote:
Well, I hope I'm not thinking about consistency for its own sake. I don't know of a specific example. It's just my sense that if one developer starts work variable names with one prefix, and another with a different prefix, one could make assumptions when they look at code. Maybe I'm not making sense. Maybe consistency is overrated.
I don't think I could ever standardise names in my system, even if all
my colleagues were 100% supportive of the idea. It would require a
complete development shutdown, massive edit/compile cycles, lots and
lots of manual effort and at the end, exactly zero functionality
improvement.
If we settled on a new naming convention, we wouldn't really solve the
issue of multiple styles; we'd still have the myriad existing styles,
and we'd actually be adding a new one - one that no one now actually uses!
The third way is to adopt a standard for new code, and to commit to
rewriting existing code as the programs come up during maintenance.
This has merit, but is often a difficult sell to management who don't
understand the idea of technical debt. And you'll still have the
problem of having to suss out the old style while rewriting /
maintaining it.
Balancing that, and speaking personally, I find that my comprehension
issues go up exponentially with the number of LOC. My comprehension is
only marginally worse with a nonstandard naming convention. Monster
programs are hard because they're monstrous :-)
I was really looking for a 'this is how we do it.' I'll sharpen my Google skills.
I've kicked the habit of writing standards documents :-) If you can get
the People's Democratic Republic of Developers to agree on a document,
you're a better man than I am. If you can get them all to follow it for
more than a month, you must have the voice of an angel!
However I do have some standards that I more or less personally follow.
If someone else modifies one of my programs and uses a different
pattern, eh. It's a mod I didn't have to make :-)
I like Java naming. So customerName, salesYtd, isEligibleForPromotion,
etc. I like my functions to return a value:
// Convert DTS to JOB
// USA is 16 bytes:
// CYYMMDDHHMMSSmmm
// 1072715000000000
dcl-proc cvtDTSJob export;
dcl-pi *n char(20);
inpDTS char(8) const;
end-pi;
dcl-s rtnval char(20) inz;
dcl-ds errorCode likeds(QUSEC);
// set up the errorCode to report errors
errorcode.ErrBytesProv = 0;
errorcode.ErrBytesAvail = 0;
callp QWCCVTDT ('*DTS': inpDTS: '*JOB': rtnval: errorcode);
return rtnval;
end-proc;
although I don't throw a fit if it returns a success/fail indicator:
* create user space
p b_crtUsrSpc b export
d b_crtUsrSpc pi n
d i_spcNam 10 const
d i_spcLib 10 const
d o_error like(api_err)
note this last one returns an error code variable as an output
parameter. I think I'm migrating toward the notion that I want to throw
an exception message and /force/ the caller to deal with errors. The
way it is now, the thing will fall over, report the error to the caller,
who can choose to ignore it. Most IBM APIs do it this way (return an
error code / structure).
If at all humanly possible, I do this:
RPG STRINGS
BND STRINGS
SRVPGM STRINGS
/copy STRINGS
This lets me simply compile any service program. It has one source
member (named the same as the service program). The binder language has
the same name, and so does the /copy which goes in QPROTOSRC. All of
the objects and source members are named STRINGS. Easy to find, easy to
work on. I like easy.
I use RDi. Not SEU-eww. With RDi I have a pair of user-created open
source addons: iSphere and RPGUnit. If you don't use RDi, well you can
still use RPGUnit from the command line. Do it. It changed my life.
Thanks Mihael and Thomas!
RPGUnit gives me TDD - Test Driven Design. This idea has increased my
confidence a thousandfold. When I make a change, I run my tests and if
they come back green, I /know/ that I haven't broken anything elsewhere.
Know, like 100% confident. It's nigh unto impossible to get existing
code under test, but all of my new code gets this treatment. When I
start at the beginning with the 'test first, not last' philosophy, I
write code that's testable, and /that/ is what has changed my life.
I'm a fan of Steve McConnell's book 'Code Complete' and I can't believe
how much stuff I learnt from a Java programmer.
midrange.com
