Difference between revisions of "Coding style/Formatting"
(rough first cut, still missing some stuff) |
m (Coding style/C/Formatting moved to Coding style/Formatting: delete one level of hierarchy) |
(No difference)
| |
Revision as of 11:14, 11 April 2008
The following coding style considerations apply to the most mechanical aspects of C source code style.
Contents
Maximum width 79 columns
Current conformance
Existing code mostly conforms to this guideline.
Rationale
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]
Current conformance
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
-
src/plugins/kdb/db2/libdb2 -
src/lib/rpc - Parts of
src/lib/gssapi/mechglue
-
- Code derived from OpenVision -- various
- Parts of
src/lib/gssapi/krb5 -
src/lib/kadm5 -
src/kadmin
- Parts of
Rationale
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.
Current conformance
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.
Rationale
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
Current conformance
Existing code is highly variable in this area. Particularly problematic are boilerplate, such as copyright notices, which contain trailing whitespace.
Rationale
Trailing whitespace is difficult to see in many editors. It can also create problems when generating patch files.
Comment formatting
BSD-style block comments. No C99 double-slash comments. Something about Doxygen.
