Date: Tue, 28 May 1996 21:39:59 +0200 (SAT) From: Robert Nordier <rnordier@iafrica.com> To: terry@lambert.org (Terry Lambert) Cc: rnordier@iafrica.com, grog@lemis.de, hackers@FreeBSD.ORG Subject: Re: Indentation styles Message-ID: <199605281940.VAA00188@eac.iafrica.com> In-Reply-To: <199605281801.LAA11424@phaeton.artisoft.com> from "Terry Lambert" at May 28, 96 11:01:22 am
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote:
> > Automatic beautifiers can only be applied
> > to complete, syntactically correct programs and hence
> > are not available when the need for attention to white
> > space and indentation is greatest.
>
> This is no longer true because of language sensitive editor technology,
> as in Brief, the UNIX "Brief clone", and the Borland and Microsoft
> offerings.
Yes, this works pretty well in currently available tools. I remember it
used to work very badly, particularly with some interpreters which wanted
to entoken everything before moving to the next line. But that's history.
> > (For those influenced by Classical allusions, the Greek legend of
> > Procrustes is also very apposite.)
>
> As opposed to "opposite" or "apostate"? 8-) 8-).
"appestat ... apposed ... epicyte ... opacity". :) :)
("apposite: well-expressed; appropriate" [COD], if anyone's guessing)
> > I think Greg's concern in valid, but this is one of Nature's
> > Insoluble Problems. Let's have some sanity, please!
>
> 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:
static char *f_args[F_ARGS] = {
"160", "180", "320", "360", /* K_ARGS */
"720", "1200", "1440", "2880",
"1.2", "1.44", "2.88" /* M_ARGS */
};
static struct BPB stdbpb[BPBCNT] = {
{512, 1, 1, 2, 64, 320, 0xfe, 1, 8, 1, 0, 0}, /* 160K */
{512, 1, 1, 2, 64, 360, 0xfc, 2, 9, 1, 0, 0}, /* 180K */
{512, 2, 1, 2, 112, 640, 0xff, 1, 8, 2, 0, 0}, /* 320K */
{512, 2, 1, 2, 112, 720, 0xfd, 2, 9, 2, 0, 0}, /* 360K */
{512, 2, 1, 2, 112, 1440, 0xf9, 3, 9, 2, 0, 0}, /* 720K */
{512, 1, 1, 2, 224, 2400, 0xf9, 7, 15, 2, 0, 0}, /* 1.2M */
{512, 1, 1, 2, 224, 2880, 0xf0, 9, 18, 2, 0, 0}, /* 1.44M */
{512, 2, 1, 2, 240, 5760, 0xf0, 9, 36, 2, 0, 0} /* 2.88M */
};
> Obviously, much of KNF style has evolved from the defaults for the
> vi editor and other tools to allow quick reference of the code (ie:
> "grep \^functionname *.c" to find:
>
> <type declarator>
> functionname( ...
>
> and so on. As long as these tools are "the approved tools", then
> there needs to be some form of style enforcement to allow them to
> work as expected (my own placement of spacing in parenthesis allows
> editor macros to directly access tags files and man pages. Obviously,
> it's also a tools-driven decision).
Yes, there's a lot of sense in that. If one is going to accept the
complex equivalence
programming == science || engineering
there hardly seems room for dispute. But there still is a (diminishing)
programming == art || craft
crowd around, to whom form is as important as function. And legislating
stylistics is going to seem like the violation of some fundamental
right (rite?) of self-expression.
I think my main point is that a "What is not forbidden should be made
compulsory" attitude is likely to make a few (maybe eccentric) souls
unhappy. And maybe the issue is just too contentious for common-sense
to prevail.
--
Robert Nordier
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605281940.VAA00188>