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.