But before you "cutover" too much of the same old "lines of stuff" -- as opposed to "lines of code" -- take a moment and ask yourself this question: "Despite the fact that I'm the smartest, slickest, and fastest TPF Programmer Analyst in the world, could I be coding my programs any better?"

In case you can't stand the thought of questioning the already high quality of your own work, try asking yourself this question instead: "Ignoring the obvious fact that my code is eons ahead of every other programmer on the planet whether it be TPF Assembler, "C" or SabreTalk, what can I do to look smarter and sound more informed so that I distinguish myself from the rest of the pack?"

To aid you in your quest to become (or to remain) the TPF guru that you already know you are, I've come up with the following checklist of things you should consider before, during, and after you crank out thousands of lines of new code in the Y2K millennium.

Are there enough comments in the code?

The lack of well-documented code is probably the most prolific problem that I've seen in the TPF industry. If you're reading this article and your response is "I don't need to comment my code, its really quite self-documenting", I beg you to find a coverage person in your shop, hand him/her your code and ask for a detailed explanation of it in 5 minutes.

Did I use the "KISS" principle?

KISS is an acronym that stands for "Keep It Simple, Stupid". It's basic concept is that when you have a choice between using a slick coding technique that you just learned or using a straightforward, and widely-practiced coding technique, then you should use the latter. The folks in coverage will owe you a debt of gratitude for doing so. They may even "kiss" you later on.

Is the module length too long?

Hey, just because your TPF modules can be 4K in size, doesn't mean that they have to be. Remember, TPF still supports those smaller module sizes. Also, if you're a TPF "C" programmer, you know that there's practically no limit to the size a TPF DLM can be. But that should serve as no excuse for cranking out unwieldy, "C" modules that have thousands of lines of unmanageable code.

Are there too many decision/branch points in any one module?

The number and location of branch statements in your programs should be checked for minimal complexity. If you find that you're writing too many unconditional branch statements, maybe you should consider using subroutines. (See point #8). Otherwise, can you say "spaghetti"?

Does the code reflect a need to do a good job or a need for job security?

Let's say you're the only person who understands a very "niche" area of your business system. That doesn't mean that you'll always be in that "niche" or even with the company. You might suddenly win the lottery or get hit by a bus. So, instead of provoking the person who takes over for you to incite every invective possible as they seek to understand your code, wouldn't you rather that they sing your praises and tout the high quality of your work?

Was code reusability considered?

Just because you're fast TPF coder doesn't mean that you have to re-code something that another programmer or project team may have already done (Even if the code isn't as good as yours would be). You can save huge amounts of time by reusing code that already been coded, tested, and loaded to production. On the flip side, you should be designing/developing the code you're working on now for possible reuse by other project teams.

Is the code lean enough?

This refers to whether or not you've added extra lines of code that's really not needed. In other words, did you have to do that extra level check or core block initialization? Do you have to re-base all of your registers in every subroutine/module? Extra code means extra time spent in testing or debugging that code.

Was code modularity used adequately if at all?

If you had to "cut and paste" the same sequence of statements into more than one location in throughout your modules, then you probably should have considered "modularizing" that code. This concept simply means isolating common code into a separate module so that programs won't have to duplicate include that same sequence of code. Instead, those programs would simply call or "Enter" the common module. Thus, instead of having code to retrieve a certain record in 5 different modules, you could place the code into one module or subroutine and have the 5 module invoke the common module and resume processing.

Are the modules "loosely coupled".

Although generally a term applied to a TPF central processing complexes, the term "loosely coupled" can also be applied to the interaction between coded modules. The idea behind this concept is that once you start using modular code, the relationship between modules should not be overly dependent. In other words, if you have a module A that invokes a module B, replacing module B with a new module C should not require module A to be rewritten because it was meant to function only with module B. Module A should have been coded at an abstract enough level so that its relationship with module B is independent of how module B accomplishes it task.

Was code portability considered?

If your shop is dreaming of one day getting rid of their TPF system, then you may want design and code your programs to make it easier for that to happen. This point is especially applicable to TPF "C" programmers since TPF's ISO-C version much more easily ported to other platforms than prior "C" versions.

For more helpful suggestions for the Y2K Millennium, consult the following helpful publications:

"Code Complete", by Steve McConnell. Published by Microsoft Press.

"Rise & Resurrection of the American Programmer", by Edward Yourdon. Published by Prentice Hall.