Code Style
Jarrett Billingsley
kb3ctd2 at yahoo.com
Fri Jun 15 13:41:36 PDT 2007
"Robert Fraser" <fraserofthenight at gmail.com> wrote in message
news:f4up7c$182q$1 at digitalmars.com...
Braces on a separate line from anything else, match up vertically. Braces
don't match the end of the previous line's keyword or something weird like
that (see the Tango source for details :P).
Indent inside every braced block (control statements, aggregate decls,
function bodies etc.).
Indent cases, then indent their bodies, break on same level as body:
switch()
{
case x:
body;
break;
default:
break;
}
Always use hard tabs set to 4.
Spaces around binary operators, no space between unary operator and operand.
Spaces after commas, never before. No space before colons and semicolons.
No spaces with parens.
Almost never align declarations/initializers. Very rarely align params in
successive function calls, except when there are a lot of similar calls.
Params always come on the same line as the function call, unless it starts
getting really long (>110 chars or so), then I put a line break after a
comma and indent one tab. Same for all long lines, really -- the rest of
the line is indented one tab from the beginning of the line.
Never use two blank lines, always one. Always a blank line after a group of
variable decls; always a blank line before a control construct. Always a
blank line between/after control constructs; I'd never do something like:
if(..)
{
}
if(..)
{
}
Looks like an 'else' is missing before the second 'if' to me.
> Also, a more general question... would you ever consider actually USING a
> code formatter/have used one in the past?
Yes, to clean up the horrible code everyone else besides me writes :D I
think most people would use it for that.
More information about the Digitalmars-d
mailing list