[GRASS5] Towards a 5.1.0 experimental release

[Glynn Clements]

H Bowman wrote:

> > > > > >  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.

-- 
Glynn Clements <glynn.clements at virgin.net>