Next: A general principle Up: No Title Previous: No Title

Quality in software

There are several aspects to the quality of a piece of software. Aside from external issues, such as ``How easy is it to use?'', the quality issues internal to the programming activity include the following:

  1. Correctness: does the program produce the required results/behaviour? This aspect of quality needs little justification: there is no point in having a beautiful, fast, all-singing-all-dancing program which doesn't satisfy the customer's requirements!

    If quality in this respect is low then nothing else matters, but attention to quality in the following points will contribute to achievement of quality in respect of correctness.

  2. Appropriate use of programming language facilities/constructs: are the best tools being used for the job? For example: are while loops being used where for loops would be more appropriate; are variables which are used only locally within procedures in fact declared at the head of the main program?

    If quality in this respect is low then, even if the program is (mostly) correct, it may be very difficult and/or expensive to maintain (to adapt to new requirements, or to correct faults uncovered during testing or by users).

  3. Good documentation: in particular we are considering the ``internal'' documentation of the program (exactly what this means is the subject of the rest of this paper).

    If the documentation is poor, then even if a program is correct, with appropriate use of language constructs, it may still be so impenetrable that it is difficult and/or expensive to maintain.

5inLet's concentrate on the internal documentation of a program. This is a collection of general observations and thoughts on style in the construction and presentation of the source text of a program.

Next: A general principle Up: No Title Previous: No Title

Simon Jones (