Re: What coding style should be used?

[Ian Jackson <ian@davenant.greenend.org.uk>]

Goswin von Brederlow writes ("What coding style should be used?"):
> as you might have seen from my other mails I'm working on mutliarch
> for dpkg. So I've patched quite a few of the source files and looked
> at more. Unfortuanetly the coding style is inconsistent. Which one
> should be used?

As the original author, and still the author of most of the code by
bulk, I think my view should be determinative.  It is of course a bad
idea to reformat code in a free software project.

I know that the current maintainers don't agree.  But here are my
answers:

> void foo() {
>   int bla;
> };

> bla= 17;

> foo(x,y,z);
unless x y z are long in which case something like

> foo(x ? 3 : 4, strange[y].zork, z);

ie both are acceptable.  Clarity is key, which means using whitespace
to ensure that more closely related subexpressions are nearby.

> for (x=1; x<10; x++) { }

which is not one of your examples.  Note
    - Exceptionally no ` ' in assignment
but use of whitespace in expressions is always a matter of judgement
 rather than hard and fast rules so
    for (x= &big[complicated(expression)];
         x < &end[complicated(array)];
         x++) {
is OK too.

> if (1) { }
> while (1) { }

in the macro encapsulation idiom:
> do{ }while(0);
otherwise I would usually write
   for (;;) {
and use break and continue

but this is hardly ever used except 

> x++;

The reasons for writing prefix in C++ don't really apply to C.

> *p++= 0;

I would prefer this unless there was a reason to do the other.

> printf("%.250s\n", package->name);
> printf("%s\n", package->name);

That depends on whether the thing needs to be limited in length.  Many
of the printfs with %.250s are sprintfs into fixed buffers.

> if (foo == 1 &&
>     bar == 2) { }

> 80 chars?

79.  But many of the lines are from an older age when I used to use up
to 90 because I was BATSHIT INSANE.  One shouldn't change those unless
one happens to be changing the code anyway, because reformatting for
the sake of it is always bad.

Ian.