Difference between revisions of "Coding style/Formatting"
(rough first cut, still missing some stuff)
Revision as of 12:14, 11 April 2008
The following coding style considerations apply to the most mechanical aspects of C source code style.
- 1 Maximum width 79 columns
- 2 Four-column basic indentation offset
- 3 No tab characters
- 4 No trailing whitespace
- 5 Comment formatting
- 6 Spacing around delimiters
Maximum width 79 columns
Existing code mostly conforms to this guideline.
A width of 79 columns fits on most terminals, and is most suitable for printing with a decent column width. Long lines resulting from deeply indented code are often a symptom of design flaws.
Four-column basic indentation offset
Every level of block nesting should be indented by an additional four columns. [needs more detail]
Existing code varies in conformance. Much of the core library code (
src/lib/krb5, etc.) conforms, but other subsystems chose different indentation offsets. Exceptions include:
- Code of BSD-related origin -- typically eight columns
- Parts of
- Code derived from OpenVision -- various
- Parts of
- Parts of
Combined with the 79-column width limit, this somewhat limits the level of nesting. This indentation offset allows for visual identification of indentation levels while avoiding long-line problems resulting from using an eight-column indentation offset with some of the long identifier names we use.
No tab characters
This guideline will probably be one of the more difficult ones to adopt in a non-disruptive manner.
Existing code does not conform. Much of the existing code was written in Emacs, which defaults to using sequential tab characters at the beginning of stretch of horizontal whitespace longer than one column.
Tab stop locations are not consistent across different editors and platforms, and can make code harder to read on a platform other than the one on which it was written.
No trailing whitespace
Existing code is highly variable in this area. Particularly problematic are boilerplate, such as copyright notices, which contain trailing whitespace.
Trailing whitespace is difficult to see in many editors. It can also create problems when generating patch files.
BSD-style block comments. No C99 double-slash comments. Something about Doxygen.