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