Sometimes, old principles might still be good.

I am new here, so please be kind :-)

But I am not new to the handicraft of programming. So, after spending a few days starting to dig into rather new source
code regarding Rock, the beginning of an old fairy tail came to my mind:

Once upon a time, when there was no object oriented language around, C simply was the 3*rd character of the alphabeth,
systems programming had to be done in long forgotten
languages called Assembler. There were different ones around, at least one very widespread "dialect" of them only had
one simple top priority rule, kept above eveything else
by the "Masters of Programming":
"Egoless programming".
The interesting point was, that these "Masters of Programming" did not need explicit
written orders to obey to this rule. They simpy recognized the impotance of this rule be reading each others code, and
obeyed to it.

This rule of "Egoless Programming" contained several aspects. Some of these were
- Use a lot of comments.
Also to allow other people to read and understand the written code, for the purpose of proofreading, or the purpose of
maintenance, or the purpose of learning,
or the purpose being the "ultimate documentation", or simply as some written reminder and guideline for the original author.

Which lead to the tradition, (almost) every assembler statement to have a comment. Sometimes related of course, to
easily show, whats happening, like this eaxmple:
XOR R1,R2 ; Exchange
XOR R2,R1 ; ... contents of
XOR R1,R2 ; ... register 1 and register 2

- Explicitly define every variable, and comment.
Of course the "Master of Programming" knew the contents of a variable. Or could imagine the contents, because of its
name. However, other people mighr have other fantasies. So,
even in case of a simple variable like
I: .BYTE 0; Loop index
this had to be explicitly stated. To be absolutely clear.

- Data structures had a pre-defined layout, in case not being used only in one module.
This layout had to be defined in its own separate source file. The name of the data structure usually also had to be the
name of the layout definition file.
For example, the control block for a hardware device had a general structure defined in DEVCB.DEF.
The items within this control block had a general syntax, like
O.DEVCB_LNK=0 ;Offset to pointer of device list
O.DEVCB_STATUS=2 ;Offset to status word; if this is not the last item any more, update L.DEVCB
DEVCB_STATUS.NONSHR = 1 ;Device sharable, Y/N
L.DEVCB = O.DEVCB_STATUS+2 ;Length of DEVCB (byte)

Having the definitions of every "common" data structure in its own file, for a new reader of the code it was easy to
find the definitions of unknown variables/structures.

Similar naming conventions were used for executable code.
Which meant: One function/module in one source file. Name of function was identical to the name of
the source file.
And every source file for executable code had a general layout.
For instance, it contained some general info comments first, most important of which to be
a short verbal description of the functionality and detailed descriptions of input and output.
Of course, some other info like author, version, date etc. were present, too.

Again, this is just the beginning of an old, almost long forgotten fairytail :-)

In case, the reader considers "Egoless Programming" an "out of date" principle, then simply ignore this mail.
But in case, the reader of this mail can detect some interesting issues, a discussion about it is welcome.

Cheers,

Reiner

-----
This eMail does not contain any virus.
Von AVG überprüft - www.avg.de
Version: 2012.0.2221 / Virendatenbank: 2639/5564 - Ausgabedatum: 28.01.2013
Received on Tue Jan 29 2013 - 10:51:13 MST