logo_kerberos.gif

Coding style/Formatting

From K5Wiki
< Coding style
Revision as of 20:07, 9 April 2008 by TomYu (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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

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.

Current conformance

Rationale

Spacing around delimiters

Current conformance

Rationale

Personal tools