C Coding Standards

CptS 150

  1. Introduction
    This standard provides the basic accepted format for programs in the C language. The general intent for the standardization of software is to make the software maintenance task as simple as possible. Each programmer has a favorite way of doing things and some of the guidelines presented here will undoubtedly infringe on that, but it is generally more important to provide a consistent format for the software maintenance task than to persist with personal programming habits.
  2. General Format
  3. Naming Conventions
  4. Comments
    Comments are among the most important parts of any program. They make it possible to understand code quickly and thus make it more likely that modifications to code will be correct and will increase programmer efficiency and productivity. Novice programmers tend to avoid writing comments until the code is complete. Often, the rationale for this neglect is that programmers assume that the code will change as debugging proceeds and that the comments will also need to change. Therefore, they believe that writing comments along with the code is just a waste of time. This is nearly always a mistake. Writing comments as you write the code often helps clarify exactly what it is that you are trying to accomplish, thus making errors less likely. Furthermore, it takes less time to comment when the tasks you are performing are fresh in your mind. You will undoubtedly find that with the first programs you write, this is not necessarily true. As your programs get longer, however, you will need to spend increasing amounts of time reviewing your code to be able to write comments if you leave them till last. As a result, it is best to get into the habit of commenting as you write your code from the very beginning.

    Comments, or documentation, fall into two major categories:
    1. External Documentation
      External documentation consists of a top-down design and an overview of the specifications and function of the entire program, along with a description of the interface between files in a multi-file program. This interface section must include a list of the files that comprise a program, the function of each file, and the specifications for the publicly accessible variables, constants, and functions that each file provides. 
    2. Internal Documentation
      Internal documentation consists of four types:
      1. File header comments:
        At the beginning of each file, a comment block of the following form must appear:
        /*********************************************************
        *Programmer: 						*
        *Program #:						*
        *Lab Section:						*
        *Date:							*
        *Description:						*
        *********************************************************/

        Fill in each section as appropriate. The "Description" section should contain a brief, plain English description of the purpose of the program. 

      2. Function header comments: 
        These may appear either immediately preceding the function header or immediately afterwards. The function header comment block has the following form:
        /*********************Function Name**********************
        *Description:						*
        *Implementation:					*
        *Interface:						*
        *Callees:						*
        *Comments:						*
        *********************************************************/

        The "Description" is a brief, plain English description of the task that the function performs. The "Implementation" gives a high-level view of the algorithm used to perform the task. This may be in plain English or pseudo-code. The "Interface" section specifies the nature of the inputs (parameters) and outputs of the function. The "Callees" section lists the functions that the current functions calls, including any library functions. If the function calls subroutines in other files, this section must specify the file in which a called subroutine is located. The "Comments" section is in some ways the most important part of the header comment block. In this section you must state any preconditions, or assumptions that must be true before the function is called in order to guarantee that it will work correctly. You must also state the postconditions; those things that will be true once the function has executed. You should also state here any side-effects that the function produces, such as changes to global variables or input from the user or from a file or output to the screen or to a file.

      3. Section comments:  
        These comments occupy one or more full lines (indented to the same level as the block they describe). They give an overview of a section (generally comprising several statements) of a function when this section performs an identifiable subtask within the function. Such full-line comments are common before a loop, but may also be helpful when they precede a short series of statements. Use blank lines before and after a section to make it apparent where the section begins and ends.

      4. Line comments:
        These comments explain a single statement of the source code. They appear in the right margin of the code and follow the statement they explain. Your code will be more readable if you line them up. For example:

        sum = 0;  		/* initialize the sum */
        while (sum < 100) {
          printf ("Enter a positive whole number:\n");
          scanf ("%d", &i);	/* read a user-entered */
        			/* number to add to the sum */
          sum += i;
        }
        If you use meaningful identifiers and choose algorithms that are inherently clear and simple, you should not need many line comments. If you are in doubt about the clarity of your code, however, they are appropriate and useful. Be sure that such comments are not simply a plain English version of the C statement, but instead serve to explain why the statement is necessary or what the statement is doing. One place you should always include line comments is in a complicated or nested if-then-else statement. This sort of line comment will state what must be true at each point in the code. They are also useful just after a closing brace when a function includes nested blocks or at the end of a function. In this latter case, use them to clarify which block the closing brace is terminating. For example:
        while (i < 10) 
        {
          if (x > y)
          {
            if (y > z) 
            { 			/* x > y > z */
              ... ;
            } /* if (y > z) */
            else 
            {			/* x > y && z >= y */
              if (z > x)       	
        	... ;
              else 			/* x > y && z <= x */
            } /* else x > y && z >= y */
          } /* if (x > y)
          else 				/* x <= y */
            ... ;
          ++i;
        } /* while (i < 10) */

        Line comments are also necessary whenever you declare a variable or constant to describe the use or purpose of each such identifier.

  5. Structuring and Indentation
    The overall structure of the program must be organized as follows (in the following order):
    1. program header comment section
    2. #include statements
    3. #define statements
    4. type definitions
    5. functions organized in a logical manner 
    6. the main function
    Proper indentation makes code more readable and thus easier to modify and debug. This is particularly true with nested blocks. The placement of braces also helps to make the structure of the code more apparent and makes it less likely that errors will occur when braces are improperly matched. Placing each brace on a line by itself is the safest practice.  This placement will make it easier to determine that each opening brace has a corresponding closing brace in the right location. Whenever a block is nested inside another block, the inner block must be indented by either two or three spaces (be consistent).
  6. Forbidden Practices
    Do not use global variables unless the variable is used in virtually every function in the file.
    Do not use GOTO statements.