Re: Unit tests

[Rich Felker <dalias@aerifal.cx>]

On Tue, Apr 26, 2011 at 11:14:30PM +0400, Solar Designer wrote:
> Rich -
> 
> You could want to define the coding style for the project, perhaps to
> match musl's.  For example, in Owl we're using a coding style similar to
> that achieved with the following "indent" program options:
> 
> indent -kr -i8 -nlp -nbbo -l79 -lc79
> 
> (these are given in Owl/doc/CONVENTIONS).


musl's indention style is pretty close to k&r, basically the
following. i'd be happy if the unit tests project can do similar:

- use tabs for indention levels; set them to show up at whatever width
  you prefer in your editor.

- avoid using so many indention levels (assuming 8-space tabs) that
  you have to exceed 79 chars or break up lines too often.

- use spaces for alignment, i.e. if you want to extend past the
  indention level to line up continued lines, data tables, comments.

- put braces on new line only for function bodies, otherwise on the
  same line as the loop/conditional statement. braces before and after
  else statements should be on the same line as the else. within a
  single if/else if/else construct, be consistent - use braces for all
  of them or none of them.

- uses spaces after conditional/loop keywords, but not after the
  function name in declarations/calls.

- otherwise, there is no strict rule for spaces, but avoid excessive
  spaces and try to use them to highlight operator precedence as
  alternatives to inserting redundant parentheses. (i find nested
  parentheses hard to track visually, guess that's why i never liked
  lisp... ;-)


rich