Lint is a C program checker [2] that examines C source files to detect and report type incompatibilities, inconsistencies between function definitions and calls, potential program bugs, etc. It is expected that projects will require programs to use lint as part of the official acceptance procedure. In addition, work is going on in department 5521 to modify lint so that it will check for adherence to the standards in this document.

It is still too early to say exactly which of the standards given here will be checked by lint. In some cases such as whether a comment is misleading or incorrect there is little hope of mechanical checking. In other cases such as checking that the opening brace of a function body is alone on a line in column 1, the test has already been added. Future bulletins will be used to announce new additions to lint as they occur.

It should be noted that the best way to use lint is not as a barrier that must be overcome before official acceptance of a program, but rather as a tool to use whenever major changes or additions to the code have been made. Lint can find obscure bugs and insure portability before problems occur.

Special Considerations

This section contains some miscellaneous do’s and don’ts.

  • Don’t change syntax via macro substitution. It makes the program unintelligible to all but the perpetrator.
  • There is a time and a place for embedded assignment statements). In some constructs there is no better way to accomplish the results without making the code bulkier and less readable. The while loop in section 8.1 is one example of an appropriate place. Another is the common code segment:

    Using embedded assignment statements to improve run-time performance is also possible. However, one should consider the tradeoff between increased speed and decreased maintainability that results when embedded assignments are used in artificial places. For example, the code:

    should not be replaced by

    even though the latter may save one cycle. Note that in the long run the time difference between the two will decrease as the optimizer gains maturity, while the difference in ease of maintenance will increase as the human memory of what’s going on in the latter piece of code begins to fade.
  • There is also a time and place for the ternary ? : operator and the binary comma operator. The logical expression operand before the ? : should be parenthesized:

    Nested ? : operators can be confusing and should be avoided if possible. There are some macros like getchar where they can be useful. The comma operator can also be useful in for statements to provide multiple initializations or incrementations.
  • Goto statements should be used sparingly as in any well-structured code. The main place where they can be usefully employed is to break out of several levels of switch, for, and while nesting, e.g.

    When a goto is necessary the accompanying label should be alone on a line and tabbed one tab position to the left of the associated code that follows.
  • This committee recommends that programmers not rely on automatic beautifiers for the following reasons. First, the main person who benefits from good program style is the programmer himself. This is especially true in the early design of handwritten algorithms or pseudo-code. Automatic beautifiers can only be applied to complete, syntactically correct programs and hence are not available when the need for attention to white space and indentation is greatest. It is also felt that programmers can do a better job of making clear the complete visual layout of a function or file, with the normal attention to detail of a careful programmer. Sloppy programmers should learn to be careful programmers instead of relying on a beautifier to make their code readable. Finally, it is felt that since beautifiers are non-trivial programs that must parse the source, the burden of maintaining them
    in the face of the continuing evolution of C is not worth the benefits gained by such a program.