Date: Wed, 29 May 1996 16:35:00 -0700 (PDT) From: obrien@cs.ucdavis.edu To: chat@freebsd.org Cc: thorpej@nas.nasa.gov Subject: Re: Indentation styles Message-ID: <9605292335.AA16928@dana.cs.ucdavis.edu> In-Reply-To: <199605291802.UAA00619@eac.iafrica.com> from "Robert Nordier" at May 29, 96 08:02:19 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> [...]
> > >> At one time I suggested running a "beautifier" on code as part of the
> > >> CVS commit process. I still like the idea.
> > >>
> > >> I also like the idea of running a local style template on checkout
> > >> from a CVS tree. 8-).
> > >
> > > A local style template on checkout isn't a bad idea. If only 'indent'
> > > were just a little smarter. But (just when things seem to be going
> > > well) it comes up with:
One of biggest problems I see with indent (I last seriously looked at GNU
version 1.8 two+ years ago) is that it doesn't truly tokenize your code.
Meaning it doesn't turn the input stream of your code into an basic
stream of tokens and then output those tokens based on the active
formatting rules.
With indent, the input format has too much affect on the outputed format.
Thus I can feed indent the same code formatted two different ways, run
them through indent with the same options and get two different outputs.
So before being able to use indent in this way, it *does* need to made
smarter. [it is also in *DIRE* need of a complete re-write -- it has
been hacked for so many years by so many different places and people,
that adding more functionality to it is a real mess! (esp. GNU's indent)]
I had to write a little memo on this once at a company that wanted to do
exactly this (using indent such that everyone coded their way and on
check in to the VCS/CM system format the code the the "standard"). If
anyone is really interested, I can post the arguments against indent from
it.
As a side note, one should also consider if they really want their code
being formatted in a very strict way. I (and some I've seen) have a
standard way they like to format code, BUT that style has exceptions in
certain cases. For instance, I may do:
if (foo) return 0; /* done only for things like return, not all
one liners */
but generally prefer:
if (foo) {
bar;
} else {
baz;
}
And I might use a more KNF when if conditions that are really, really
long. It would be too hard to codify this in a set of rules. I try to
code what I think is most pleasing and conveys information the best.
(The wisdom of mixing styles and whether these styles really do, is left
to follow-ups).
-- David (obrien@cs.ucdavis.edu)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9605292335.AA16928>