I have a page (page 1), dated February 2, 1989 that my former boss presented to me, outlining Niman's 13 Minimally Sufficient Commandments for programming. (He recognized that they were dated, making this more of an archaeology piece than a modern set of guidelines.) If you haven't seen them, they are as follows:
- Thou shalt adequately comment thy code in order to explain what thou intendest. Man does not think by mnemonics alone.
- Thou shalt equate numeric constants to meaningful symbol names. Speak clearly and avoid pagan icons.
- Thou shalt describe all inputs and outputs in thy modules. Be kind to thy software brethren and sistren who may have to maintain thy modules.
- Thou shalt adequately describe thy revisions. It is a sin to expect your peeren to be mind-readers. Mind-reading is a sin anyway.
- Thou shalt provide pseudocode explanations of thy assembly code. Verily, assembly is not Cobol.
- Thou shalt have only one entry- and one exit-point per module. He who has many entry- and exit-points shall expect their bodies to develop same.
- Thou shalt design thy code prior to developing it. Verily, indeed.
- Thou shalt conduct reviews of thy code with thy peeren. Blessed be the meek, for they shall inherit the object code.
- Thou shalt document thy design and make the documentation available to all who maintain the code. Verily, he who refuses shalt debug forth operating systems forever in hell.
- Thou shalt be able to accept meaningful criticism of they code. If thou art ashamed of thy code, thou should become a professional bowler.
- Thou shalt throughly (sic) test thy code prior to placing it into library control. One part left out of the Bible was where Job was tested by God by having to debug a large 8096 assembly language program that was part of a disel engine controller. The entire thing was not tested before release. To make things worse, Job had to use Intel tools.
- Thou shalt avoid the use of global data structures, wherever possible. Towers shalt be named Babel, programs should not.
- Thou shalt use high-level language when thy assembly programmers cannot match the efficiency of optimally-compiled, late twentieth century code. Beware of false gods who think that assembly is always more efficient (with respect to speed and size) than what good compilers can produce. Thou must be very good with design as well as coding to really take advantage of assembly language.
I've scoured the internet has revealed nothing as to the source of these commandments, or that of Niman, and it's been killing me trying to find out more about this and any other bits he might have had to say. The only other clue I have is that in the lower left, there are the initials "DEN" - I assume N is for Niman, but I have nothing else to identify the text. So,
A. Who is Niman? (Programmer? Teacher? Consultant? Random guy at a company?)
B. What was this page from? (an old programming guide? some company manual? Some BBS back in the day? )
C. Where's the rest of it? (Is there more? What else is there? Was this a stand alone thing?)
In response to the comments, my boss has since passed on, but before that, he was in the biz for a long, long time, greybeard and all. By the color of the paper, I'm fairly certain that the date (1989) is an roughly an date of when it was printed.
The Donald E. Niman found by Mark is the correct one. I should know because it's me. That is a 22 year old thing that I wrote while I was a Cummins Electronics, Inc., in Columbus, IN. It is a bit outdated and I've learned things since then so it should be taken for the proverbial grain of salt. Donald E. Niman, Phoenix, AZ.