Background of the Clipper coding standard

Why

While working in teams of programmers on several projects that were going on for many years I realised that our quality could be improved. I looked for a way to test the team effort in all respects to guarantuee that it worked properly. Testing it a number of times showed some parts of the functionality were buggier than others. On reviewing those parts, I realised that programmers from the past had been working without consulting on eanother with their own standard, on existing functions (writing their own) and without (in some cases) proper design. One of the outcomes was to standardise the coding process based on ideas from the team and ideas from C, C++ and Visual Basic coding standards. And there it was: the Clipper coding standard. I have generalised it so it includes guidelines we don't use but I have seen them being used in other Clipper code.

Note

There is a distinct difference between code that is proven to work and code according to coding standard. The first is the goal to achieve, while the second is a method to achieve the first. All these guidelines are based on projects in which many programmers have to share their code, and on other coding guidelines. For instance, the guideline to place one line of code on one line is coming from Les Hatton's C/C++ coding standard. So if a certain coding guideline in this standard says to program in another way than the programmer is used to, it does not mean the code is bad or bad formatted.

There are circumstances in which a coding guideline along with reviews might be counter-productive. For instance when a project is done by one programmer, and it is clear that it will be the only programmer that will ever work in the code. If a project is done by an experienced programmer that has proven to be able to deliver a good code design and almost bug free code. Or a run-once tool for which the environment is well-defined (for instance for a run-once conversion) that is created by one programmer and should not be maintained. In such cases it is more important to test the functionality, then it is to review the code. If the tests show more bugs than originally expected, then a review might be worthwhile.

Background of specific guidelines

As an answer to the comments I have received to the first released version of the coding standard, hereby per remark a specific answer.

Limiting function to 60 lines
Phil Barnett wrote: "One comment on limiting functions to 60 lines. Never make code more complicated than it needs to be to solve the problem at hand and never make it less capable than it needs to be to solve the problem at hand. If you can make code simple, then make it so, but never make code simple at the cost of not having it do what it must do."

This guidelines originates from the C/C++ coding standard of Les Hatton, which in fact is even more rigid stating that a function should be limited to one A4 (printed with a 12 points font). A function that is longer than that is more difficult to review.
Take a New function that initialises a set of about 70 Class variables. Since each initialisation is on one line, this would clearly require more than 60 lines of code. As such, this guideline to limit the code to 60 lines is useless. But a Class with 70 variables could mean that the class is poorly designed. So any function of over 60 lines of code is worth reviewing. If during review there is no comment on the function, then the function is accepted.
I agree with Phill that you should never make code more complicated just to fit in the coding standard. A programmer should use his or hers brains (if available), also in applying this (or any) coding standard.