Coding style

Russ Allbery rra at
Tue Sep 7 18:05:00 UTC 1999

I'm pretty agnostic on coding style and willing to work with whatever
people want, but INN is currently such a hodge-podge of things that
there's no clear standard coding style, so I've mostly been converting
everything to something closer to my standard style as I go.  This is a
ping to see if anyone objects strongly to any of the specific tendencies I
have; if they do, please let me know, and I'll try to curb them.

I'm guessing that "write however you want so long as it's vaguely readable
and you're actually writing code" pretty much sums up how most people
feel, including me, so if you don't find any of the following strongly
objectionable, no need to reply.  :)

Here are my tendencies:

 * Untabify everything I work on.  I won't go overboard and untabify whole
   files unless I'm touching basically the whole file, but my editor won't
   ever insert literal tabs and I tend to detabify everything in the
   immediate vicinity when I go over a piece of code.

 * Four space indents, no space before opening paren of a function, one
   space between the close paren of a cast and the thing being cast, no
   space after an open paren or before a close paren, no space before the
   semicolon at the end of the line, if statements with a single-line body
   written all on one line if they fit in 76 characters.  Single-space
   indents for each level of nested #if/#ifdef, between the # and the
   keyword.  Brackets on the same line as if/while/for and cuddly with

 * Function definitions written with the type on a separate line like:

        main ()

   to allow grep ^function to quickly find the function definition.  (Tags
   tables make this technique somewhat obsolete, but it's good for large
   source bases where not everyone is going to build the tags tables.)

 * I normally don't try to line up the names of variables declared at the
   beginning of a function, but that idiom is so widespread in INN that
   I'll probably adopt it for INN coding.  I prefer:

        char *  p;


        char    *p;

   though when doing it, since to me * is part of the type, not part of
   the variable name.

 * Comments using the:

        **  Two-space indent, two starts, large block.

   style at the top of each file and before each function, briefly
   describing what the function or the file does and going into depth
   about implementation peculiarities if necessary.  All other comments
   are written like:

        /* This is
           some random comment
           about foo. */

   I tend to avoid comments on the same line as code.

 * I tend not to use NULL; I use plain 0 instead, casting it when passing
   it to a function without prototypes or a variadic function.  This is a
   long and annoying philosophical debate, largely due to the fact that
   there is no real technical advantage for either method.  0 cast to
   void * is minorly less portable in a very obscure edge case (when
   passing a null pointer to a variadic function on a system that uses
   different internal represenataions of the null pointer for pointers to
   different objects) that I highly doubt we'll ever encounter in
   practice.  I personally find:

        if (p) free(p);

   to be cleaner and easier to read than:

        if (p != NULL) free(p);

   which is probably due to the fact that I'm a Perl programmer.

 * INN's widespread use of studly caps gets on my nerves, although I
   promise I won't try to "fix" it all.  :)  But internal static functions
   in stuff that I'm working on will tend to be all lowercase with _
   separating words, since I find that much easier to read.  I really like
   INN's current naming system for external functions, namely
   SECTfunction() where SECT is some representation of the part of INN the
   function comes from, in all caps, and will try to use that where

Yell of any of the above is likely to seriously annoy you.

Russ Allbery (rra at         <URL:>

More information about the inn-workers mailing list