[prog] C and curly braces - question of style?

[Akkana Peck]

I agree with everyone who said "pick a style you like for your own
code, and be flexible but consistent when working with other people".

Jenn Vesperman writes:
> On Mon, 2004-08-23 at 11:10, Jacinta Richardson wrote:
> > But as someone else has said, whichever you choose *be consistent*.  In 
> > particular use a consistent indent level.  One tab, or x many spaces... 
> > Don't indent in some places and not in others.
> 
> I prefer that people indent using tabs, not spaces. If you want a
> narrower tab level than is standard, set it in your editor.

I dislike code indented with tabs.  Why?  Because if I print it
on a printer, or view it in a normal terminal, tabs display as
eight spaces and the code becomes hard to read (and probably
doesn't fit in 80 columns any more, so the ends of lines either
wrap or disappear).

Using tabs is fine, IF everyone in the project agrees on
the tab spacing AND IF you always use an editor to view your
code.  (Or if, as in the linux kernel style, you keep tabs set
to eight spaces and make sure everybody knows it.)

And speaking of 80 column lines: please do.  Even if you have no
patience for people who like to work in narrow terminals/editors
(perhaps because we want to have another terminal visible to work
in while still looking at the code), if you ever print hardcopy,
it works a lot better if you stick to 80 columns, and it wastes
a lot less paper.  Also, visual diff programs like tkdiff work
a lot better with 80 column lines.  (Anyone who disagrees, please
speak up.  I know Windows and Mac programmers usually disagree
with this, and think long lines are just fine; are there many
Linux programmers who feel that way?)

> If you mix tabs and spaces, however, that indentation magic breaks as
> soon as you find someone with a different tab depth. They (or you) get

Unfortunately, most people inevitably end up mixing tabs and spaces.
For example, suppose you use a 2-character tab stop for a line
that looks like this:

        if (foo_is_some_long_condition(bar)
            && something_else_that_would_not_have_fit())

If your editor inserts tabs for every two spaces, someone who
uses 8-space tabs will see that line looking like this:

                                if (foo_is_some_long_condition(bar)
                                                && something_else_that_would_not_have_fit())

Not only is it really long (and goes off the right side if you're
using an 80-column terminal or printer), but the second condition
is no longer lined up with the first one.  Hard to read!

(BTW, whether to put that && at the end of the first line or the
beginning of the second is another matter of taste.  Most people
don't seem to have strong feelings either way, but a few projects
specify one or the other.)

> You can even stick a line in your make file that formats code according
> to the group's standard at compile time, just to make everyone happy
> with a minimum of human effort. It'll take .. microseconds for the
> computer to reformat things? Geee.....

Don't do that if you're working in a CVS repository!  It'll really
mess up your CVS history when every file gets every line modified
on every checkin, because each person makes whitespace changes
every time they compile.

But Jenn, you're our CVS guru.  Are you assuming some CVS solution
to this that the projects I've worked on aren't aware of?

	...Akkana