> > > > > 1. Uniform coding style.
> > [...]
> > > > > Step 1 boils down to choosing a set of switches for the
> > > > > "indent" program, then running indent on all source files.
>
> I think that we should be more prescriptive, i.e. we should specify a
> setting for most options. Also, we should specify either -bbo or
> -nbbo, even if we don't intend to use -lN, so that authors know where
> to break long boolean expressions.
>
> FWIW, my preference would be:
>
> -nbad -bap -bbb -nbbo -nbc -bl -bli0 -bls -cbi0 -ncdb -nce -ci4 -cli0
> -ncs -d0 -di0 -fc1 -nfca -hnl -i4 -ip4 -l80 -lc80 -lp -npcs -pi4 -nprs
> -npsl -sbi0 -sc -nsob -ss -ts8
>
> However, much of that is arbitrary; I'll live with whatever is
> ultimately chosen (except -ts8; that's a technical issue rather than a
> preference).
How fool-proof is indent? Does it require checking & testing of every
converted file?
In view of what it does (i.e. insert/remove whitespace), I would
expect it to be foolproof (at least in the sense that the C compiler's
interpretation of the file will remain unchanged). In C, whitespace is
only significant in a few specific contexts (e.g. character and string
literals, preprocessor directives), and they are easy enough to
distinguish.
OTOH, one area which could theoretically cause problems is if you have
source-processing tools which impose additional constraints beyond
those imposed by C itself; e.g. Doxygen comments. Most such tools
limit themselves to comments, so leaving comments untouched might be
wise.
> > > > 1. Uniform coding style.
> [...]
> > > > Step 1 boils down to choosing a set of switches for the
> > > > "indent" program, then running indent on all source files.
> > >
...
I think that we should be more prescriptive, i.e. we should specify a
setting for most options. Also, we should specify either -bbo or
-nbbo, even if we don't intend to use -lN, so that authors know where
to break long boolean expressions.
However, much of that is arbitrary; I'll live with whatever is
ultimately chosen (except -ts8; that's a technical issue rather than a
preference).
Should the "-nut" (--no-tabs) option be used as well? Using the above
rules the first "tab stop" is four spaces, the second is one tab, the
third one tab + 4 spaces, the forth 2 tabs, etc. The -nut option
replaces the tabs with 8 spaces and makes text editors with an optional
tab size a lot happier. Downside is larger file sizes.
> > > > > 1. Uniform coding style.
> > [...]
> > > > > Step 1 boils down to choosing a set of switches for the
> > > > > "indent" program, then running indent on all source files.
> > > >
...
> I think that we should be more prescriptive, i.e. we should specify a
> setting for most options. Also, we should specify either -bbo or
> -nbbo, even if we don't intend to use -lN, so that authors know where
> to break long boolean expressions.
>
> FWIW, my preference would be:
>
> -nbad -bap -bbb -nbbo -nbc -bl -bli0 -bls -cbi0 -ncdb -nce -ci4 -cli0
> -ncs -d0 -di0 -fc1 -nfca -hnl -i4 -ip4 -l80 -lc80 -lp -npcs -pi4 -nprs
> -npsl -sbi0 -sc -nsob -ss -ts8
>
> However, much of that is arbitrary; I'll live with whatever is
> ultimately chosen (except -ts8; that's a technical issue rather than a
> preference).
Should the "-nut" (--no-tabs) option be used as well? Using the above
rules the first "tab stop" is four spaces, the second is one tab, the
third one tab + 4 spaces, the forth 2 tabs, etc. The -nut option
replaces the tabs with 8 spaces and makes text editors with an optional
tab size a lot happier. Downside is larger file sizes.
That will only make a difference for people who have configured their
text editor to use a tab spacing other than 8. If no-one does this, it
doesn't matter. If someone does do this, they will have to remember to
fix any tabs which they have inserted before they commit their
changes.
Furthermore, it isn't enough to do it once at the outset; for it to
have any use, all subsequent changes (even by people who use 8-column
tab stops) will have to use only spaces.
Anyone who sets their text editor to use a non-standard tab width is
bound to be used to dealing with files which don't abide by their
personal preference.