[Santa Clara University]
Department of Mathematics
and Computer Science

Program Style
Math 10, Math 61

Introduction

Program style is a major concern in contemporary programming practices. Since it is rare that any significant program is written by a single programmer, but rather by a team of programmers, it is important that all parts of a program be readable to other people.

Thus there an emphasis that programs should be modular (that is, make use of short segment calling other segments [i.e., functions, procedures, subroutines]), be well documented (that is, use comments within the code, mnemonic variable names, and labeled output), properly indented be at least minimally efficient (that is, avoid multiple algebraic computations or function calls), and use tested routines (that is, make use of well-known common routines, such as searching or sorting codes).

(See Math 10 Notes N1 (section 16) and Math 10 Notes N3 for additional information about programming style. See Math 10 Notes N7 about avoiding global declaration of variables. See Math 10 Notes N15 about the two styles to use when classes include member functions.

Modularity

(See Math 10 Notes N6 for additional comments about modularity.)

Modularity means that a larger program is written in several smaller segments. As a general rule, each segment should be only about a page long and should usually do only one major thing (e.g., sort, readin, printout, search).

Modularity implies that the main program is often only a series of calls to other program sections, for example: 

          int main()
	  {
	       dataline list[100];
	       Infile.open("input.dat");
	       Outfile.open("output.dat");
	       readin(list[],Infile);
	       process(list[]);
	       sort(list[]);
	       printout(list[],Outfile);
	       Infile.close();
	       Outfile.close();
	       return 0
	   }
This style of programming makes it clear what the flow of the program is and can assist the programmer (or an associate) in debugging.

(See Math 61 Notes 1 for comments on "Writing Longer Programs.")

Labeled Output

Comments should be included near the top of any program file to indicate the author's name, date of creation of the code, and a synopsis of what the code does.

It is also standard practice to include similar information in the output, so that if the output is separated from the program code, it is obvious who the author is and what the output is doing.

Subprograms

When writing routines for well-known algorithms or data structures (e.g., searching, sorting, stacks, queues), it is often better to make use of tested and published code rather than rely on personal creativity. In other words, novice programmers can save time and energy and avoid errors by copying code from a book or a web page, rather than trying to re-create a searching or sorting routine by themselves.

Any subprogram can call any other subprogram, but normally this should be avoided if it would be the last step in a subprogram. The reason for this prohibition is simple.

If the main program calls A, and the last step in A is to call B, and the last step of B is to call C, then an analysis of the main program leads to the erroneous conclusion that the main program merely invokes a single routine to do one segment of the program. On the contrary, the actual program flow is that there are three segments that are, in fact, invoked by the main program, A, B, and C, but the invocations of B and C are "hidden" because the less-than-ideal programming style. This practice in a sense amount to a pseudo-recursive type of subprogram calling, in that when the last subprogram completes its action, it must return to the previous one which in turn returns to the previous one, etc., before it returns to the main program.

This page is maintained by Dennis C. Smolarski, S.J. dsmolarski@math.scu.edu
Last changed: 24 April 1999.