Further Considerations
Validating and Testing
Data Validation
Input data must be correct. Incorrect data is often supplied through the keyboard or other electronic input devices (Bar code scanners etc.). A significant proportion of a programs code will be written to validate the users input.
One method is to return the input to the screen to request the user to check its validity. This cannot always be practical (time and effort).
User errors can be a simple as trying to input Integers instead of Characters and vice versa.
Testing
A method of solution (algorithm) should handle and process all data correctly. Sample data, of adequate ranges, should be used to test the algorithm. Extreme values should be used where limits are set.
Testing with Trace Tables
This is one method of attempting to correct a program that gives incorrect results. The idea is to debug a program by tracing data entry and processing on paper, following the paths of the finished program design. The aim is to ensure that the design functions correctly. Faulty results will show a faulty design. If the results from the trace table are good, the indication is that the problem may lie with incorrect code.
Program design to add integers in sequence 1 to 10 and check how many imtegers required to exceed a set target.
1.1 write out "Enter target, which must be a positive integer: " 1.2 read in Target 2 Sum <— 0 3 Next <— 1 4 loop while Sum <= Target 5 Sum <— Sum + Next 6 Next <— Next + 1 7 loopend 8 write out "Number of integers used to exceed ", Target, " is ", Next
| Target is 8 - Condition 4: Sum <= Target | |||
|---|---|---|---|
| Step | Sum | Next | Condition 4 |
| 2 | 0 | ? | |
| 3 | 1 | ||
| 4 | true | ||
| 5 | 1 | ||
| 6 | 2 | ||
| 4 | true | ||
| 5 | 3 | ||
| 6 | 3 | ||
| 4 | true | ||
| 5 | 6 | ||
| 6 | 4 | ||
| 4 | true | ||
| 5 | 10 | ||
| 6 | 5 | ||
| 4 | false | ||
| 8 | |||
Debugging Programs
Errors in design/code can be classed, roughly, as syntax (structure) or semantic (meaning).
Syntax concerns the structure of the relevant programming language in use. The compiler fails to understand code written. Mispelt identifiers, missing semi-colons or brackets and common typing errors are included here. Compilers generally report such syntax errors, showing where and why there is a problem. Errors with semi-colons may not be reported so well. The compiler will not know a semi-colon is missing until later in the code.
Semantic errors (bugs) are errors of the program logic. The compiler translates the code but the program does not run correctly. The program may give wrong results or may crash or hang. The program does not know what the program writer wants it to do. It just does what it is written to do. Semantic errors may be well hidden, requiring extensive debugging. Semantic errors may result from a faulty design or misplaced brackets/semi-colons.
Common errors
- Mispelt identifiers - C++ is case-sensitive
- Wrong symbols - e.g. '=' instead of '=='
- Missing variable declarations
- Missing parentheses
- Misplaced or missing semi-colons
- Missing or misplaced braces
The compiler may not report all syntax errors. These may be compiled and run, and in so doing, may give erronneous errors. Indentation can help in marking where appropriate semi-colons/parentheses/braces should be, by highlighting the program constructs.
Walking through a program
Programs can be walked through as an aid to finding bugs. This is achieved by stepping through individual program steps. A Watch List is compiled of relevant identifiers and conditions. A line of code can be selected as a Breakpoint, a position at which code execution is paused.
A program can be executed by means of the Step Over facility. Here, the execution is carried out one step at a time.
Comments, suggestions, ideas to
Stuart Banner
