Laserfiche WebLink
** DateAuthorComment <br />** 3-9-94Steven A. Malers, RTiFirst version of routine. <br />** 5-1-94SAMFixed bug where only first <br />**10 points were returned. <br />** <br />** VariableI/ODescription <br />** errcodeGError code. <br />** i, j, kLLoop counters. <br />** nptsI/OOn input, size of "stage" and "q", <br />**Lon output, the # of points in curve. <br />** ptLGeneric string pointer. <br />** stageOStage values. <br />** stationIName of station of interest. <br />** qOFlow values for stage. <br />*/ <br />int GetRatingCurve (char *station, int *npts, float *stage, <br />float *q ) <br />{inti, j, k; <br />char*pt; <br />... <br />} <br />Although the exact format of the comments is not critical, the items in the comments are important. <br />Comments should span up to 80 columns but no more. The notes provide a description of the <br />routine. Numbered notes are used so that specific items can be easily modified or deleted without <br />having to reformat a paragraph of information. The history section allows future developers to track <br />down the author for a particular routine. The variable dictionary must contain a description of every <br />variable in the routine. This makes it much easier to modify the routine in the future and also forces <br />lint <br />the author to clean the code of unneeded variables (the program and software such as CSU's <br />Purify <br />copy of will be used to help find these). <br />Variables will be alphabetized, both in the documentation section and when declared (variables in a <br />function argument list should not be alphabetized because the order is often determined by I/O and <br />use). The variable description section will also indicate whether a variable is input (I), output (O), <br />both input and output (I/O), local (L) or global (G). <br />Use only one declaration line for each type of variable. For example, do not break the <br />inti, j, k; <br />line into three lines <br />inti; <br />intj; <br />intk; <br />This format adds more text for the eye to sort through. <br />Comments within code should consist of explanations that are thorough yet concise and should be <br />readable by developers other than the programmer. <br />2 <br />A275 05.10.94 1.05-11 Malers <br />