|
|
|
|
|
|
|
into a C++ logical expression. |
|
|
|
|
|
|
|
|
The second limitation is that the assert function is appropriate only for testing a program that is under development. A production program (one that has been completed and released to the public) must be robust and must furnish helpful error messages to the user of the program. You can imagine how baffled a user would be if the program suddenly quit and displayed an error message like |
|
|
|
|
|
|
|
|
Assertion failed: sysRes <= resCount, file newproj.cpp, line 298 |
|
|
|
|
|
|
|
|
Despite these limitations, you'll want to use the assert function as a regular tool for testing and debugging your programs. |
|
|
|
|
|
|
|
|
Testing and Debugging Hints |
|
|
|
|
|
|
|
|
1. Follow documentation guidelines carefully when writing functions (see Appendix F). As your programs become more complex and prone to errors, it becomes increasingly important to adhere to documentation and formatting standards. Even if the function name seems to describe the process being done, describe that process in comments. Include comments stating the function precondition (if any) and postcondition to make the function interface complete. Use comments to explain the purposes of all the formal parameters and local variables in a function. |
|
|
|
|
|
|
|
|
2. Provide a function prototype near the top of your program for each function you've written. Make sure that the prototype and its corresponding function heading are an exact match (except for the absence of parameter names in the prototype). |
|
|
|
|
|
|
|
|
3. Be sure to put a semicolon at the end of a function prototype. But do not put a semicolon at the end of the function heading in a function definition. Because function prototypes look so much like function headings, it's common to get one of them wrong. |
|
|
|
|
|
|
|
|
4. Be sure the formal parameter list gives the data type of each parameter. |
|
|
|
|
|
|
|
|
5. Use value parameters unless a result is to be returned through a parameter. Reference parameters can change the contents of an actual parameter; value parameters cannot. |
|
|
|
|
|
|
|
|
6. In a formal parameter list, be sure the data type of each reference parameter ends with an ampersand (&). Without the ampersand, the parameter is a value parameter. |
|
|
|
|
|
|
|
|
7. Make sure that the actual parameter list of every function call matches the formal parameter list in number and order of items, and be very careful with their data types. The compiler will trap any mismatch in the number of parameters. But if there is a mismatch in data types, there is no compile-time error. With pass-by-reference, the compiler creates a |
|
|
|
|
|