Laserfiche WebLink
Understand the scope of each routine. <br />? <br />Document the scope and function of each routine. <br />? <br />Use standard methods for debugging source code. <br />? <br />Have in place a rigorous testing program for all new code. <br />? <br />The scope of a routine indicates the amount of data that the routine changes. For example, a routine <br />may sort an array of numbers into ascending order. The routine may rearrange the input array, or it <br />may copy the array and rearrange the copy. The scope of the routine is different depending on how <br />the routine is different. Some routines may modify global variables. Such code should be avoided <br />where possible because the scope of the routine then expands outside of the routine, and debugging <br />becomes more difficult. Implementing modular code that has different levels of functionality allows <br />code to be more easily debugged. For example, if a routine is needed to sort a number of stations' <br />annual flow into ascending order, then a high-level routine should be written that calls a generic sort <br />routine. The code can then be debugged by checking data as it returns from the different routines. <br />Code that is well documented is much easier to debug than code with nonexistent or incomplete <br />documentation. Nonexistent documentation requires the debugger to "reinvent" the logic of the <br />code. Incomplete documentation may be worse than no documentation if it is misleading. One of <br />the development guidelines for the CRDSS is that every routine has a header section that describes <br />the routine and the variables used in the routine (see Task Memorandum 1.05-11). Adherence to <br />these documentation standards will ensure that later work on routines (e.g., for improvements or <br />debugging) will proceed more efficiently. The scope of each routine will be indicated by the <br />variable scopes (local, global, input, output) and by the notes provided with the routine. The <br />limitations of the routine must also be clearly indicated. Changes to code will be documented using <br />comments in revision control files for the software (see Task Memorandum 1.05-20). <br />dbx <br />Source code will be debugged both by using software tools and by "brute force." The standard <br />debugging program can be used to debug code, but is most often useful when a program crashes and <br />the crash location must be located. It is often most convenient simply to place print statements in <br />code during development so that a routine's progress can be viewed. These print statements can be <br />lint <br />removed or converted to formal debug statements when the code has been tested. Programs like <br />Purify <br />or (used by CSU) can be used to check code for possible memory errors (e.g., misallocation <br />of memory for arrays) and should be used on code before it is cleared for inclusion. Formal <br />procedures for doing so will be developed in Phase II. RTi suggests implementing several general <br />debugging routines to be used in new code. RTi has used this method successfully for other projects. <br />Routines consist of equivalents to the following (shown in C syntax): <br />#include "debug.h" <br />SetDebugFILE ( FILE *dbFILE ) <br />SetDebugLevel ( int debuglevel ) <br />PrintDebug ( int debuglevel, char *routine, char *message ) <br />The first routine sets the pointer to an open file to be used for debugging (if not called, the default is <br />"stderr"). The second routine sets the debug level for the program (if not called, the default is zero, <br />2 <br />A275 05.10.94 1.05-3 Malers <br />