Hardware Reference
In-Depth Information
Testing
It is only possible to claim that a program has been validated after exhaustive
testing in conjunction with the target hardware system. In many cases it may
be possible to test individual code modules before they are linked into the final
executable program. This may be instrumental in reducing debugging time at a
later stage.
Testing the completed program requires simulating all conditions that can
possibly arise and measuring the outcome in terms of the program's response.
A common error is that of only presenting the system with a normal range of
inputs. Comprehensive testing should also involve the simulation of each of the
following:
Unexpected or nonsensical responses from the operator or user.
Failure of hardware components (including transducers, signal conditioning
hoards, cables, and connectors).
Out-of-tolerance supplies (including complete power failure).
Noise and the effect of RF interference (RFI).
Environmental changes (temperature, humidity, etc.).
Documentation
Programmers are usually woefully lacking where program documentation is
concerned. Documentation, which is essential to make the program under-
standable, takes various forms, the most obvious of which is the comments
included in the lines of source code text.
Comments
Comments should explain the action of the source code within the program as
a whole and, since the function of the operation code and operand will usually
be obvious (or can be found by referring to the instruction set) there is no point
in expanding on it. Comments should be reasonably brief but not so brief that
they become cryptic. Also, there is no need to attempt to confine a comment
to a single statement line. Comments can be quite effective if they read clearly
and are continued over several statements to which they refer.
Headers
Headers are extended comments which are included at the start of a program
module, macro definition, or subroutine. Headers should include all relevant
information concerning the section of code in question and should follow a
standard format (see Figure 4.8).
As a minimum,
the following should be
included:
Name and purpose of the module or subroutine.
Brief explanation of the action of the code (in terms of parameters passed,
registers involved, etc.).
Search WWH ::




Custom Search