C. The achievement of solid code.

Code has to be solid. A function should be able to be changed without requiring changes in 10 other functions. To achieve this, one has to create a separation between the 'interface' and the 'interior' of a function. The interface is formed by the in- and outputs and the functions name. This part should always remain the same. The interior is the code that makes the function do what it does.

The interface should be clear enough to tell what the function does, what it needs and what it returns, without going into the details of the implementation.

The interior is the territory of its programmer. It has to do what its name states and only that.

And when readability is taken care of, you can do whatever you like with it.

If you use a function, you should use only its interface. The reason for that is that functions are evolving with the program, and their implementations can be changed. Therefore one should consider a function as a 'black box' and should never open it.

Another step up is to modules. When a program is expected to be large, it is useful to split the code up in several modules, each covering a particular part of the program (or subsystem).

For example: Input, Output and Compute, with Input being the part covering everything about input, Output everything about output, and Compute every function that does stuff with the data coming from Input.

The different modules should be as isolated from each other as possible. Passing data between them should be done by a set of functions specially written for this purpose.

Consider 2 modules: PrepareData and Output.

PrepareData has several functions handling the data which are not to be used by Output. PrepareData does have a few functions through which Output can obtain the data it needs.

On the other hand, Output has a dozen functions dealing with writing to the screen. These are also hidden from PrepareData. To allow PrepareData to write to the screen, Output has a function called PrintToScreen.

As a result of this, both modules can be changed without having to change anything in the other.

You should write extra code to protect the system against risky operations. A program crashing when incorrect data is given is a true shame. You should always check input. Also disk operations, writing to arrays, divisions, the handling of memory (creating amnd freeing variables at runtime) and pointers should come with enough extra code to make sure they can recover from a fault or at least end the program gracefully. If not, some of them can (and probably will) become a Bug (with a capital B), and this is the hard-to-find kind of bug, the one with a cloaking device. The reason for their difficulty is that they don't always let the program crash when they are executed, they just mess things up. As a result the program looks like it works fine until one innocent instruction is executed, and it finds its data in ruins.

Style is important, style as in where you put your {}'s in C or C++, how you name your variables and functions, and general layout. This is one of the best subjects on which to start a lasting discussion with programmers. Which style is best depends on your taste. Just be consistent in it.