[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 26 Apr 2011 20:32:44 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Unit tests
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
