Date: Wed, 29 May 1996 20:02:19 +0200 (SAT) From: Robert Nordier <rnordier@iafrica.com> To: grog@lemis.de (Greg Lehey) Cc: chat@freebsd.org Subject: Re: Indentation styles Message-ID: <199605291802.UAA00619@eac.iafrica.com> In-Reply-To: <199605290726.JAA19555@allegro.lemis.de> from "Greg Lehey" at May 29, 96 09:26:40 am
next in thread | previous in thread | raw e-mail | index | archive | help
Greg Lehey wrote:
>
> Robert Nordier writes:
> >
> > Terry Lambert wrote:
[...]
> >> 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 */
> >} ;
>
> You don't say how you want it to look. This looks OK to me, except
> for the hanging braces (personal taste). [...]
Here are the two original fragments:
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 */
};
What I disliked were the misaligned comments, and the failure to
right-justify the columns.
> [...] Just for giggles, I ran this
> fragment through indent and got:
>
> 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 */
> };
>
> This is pretty much what I want to see.
Really? Comments all over the place? It looks terrible! :)
(OK. OK. In fairness to Greg and 'indent', comments were nicely
aligned before 'elm' intervened.)
All right. A second pass, or different options (and probably some code
changes), can make 'indent' smarter. And it would be great if it could
be made to work completely. As I mentioned, the 'indent'<->CVS idea
seems good in principle.
No-one complains if his source is 'gzip'-ed; because he has only to run
'gunzip' to get it back again. If 'indent' _were_ capable of roughly the
same magic (and _were_ capable of handling pseudo-arbitrary local style
preferences transparently), that would remove a major potential complaint:
"Stop messing with my code".
But 'indent' isn't there yet, and it may be a big job to get it there (or
acceptably close). Which was my point in citing the code.
>
> > 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.
>
> I think this is dodging the point. The point is that one limitation
> on what you can do in working on somebody else's code is the degree to
> which you can understand it. If you can do something to improve that
> situation, this will help you achieve more objectives. One way to
> work towards this goal is to have style guides. Of course, as Terry
> point out, a lot of them are based on convention and the tools you
> use. The FreeBSD style doesn't work well with my tools, which is why
> I sent out the original message.
Well, 'religious' objections typically do sidestep the real issues. I
wasn't necessarily advancing this as 'sense', but (though possibly
less on -hackers than elsewhere) this whole style business frequently
generates an extraordinary amount of heat. However, in my original reply
to your message, I think I was overestimating the FreeBSD hacker interest
(one way or the other) in the issue.
Still, I'm not entirely sure what you mean by 'dodging the point'. As
I understand it, a possible scenario is as follows:
G: I want everyone to reformat their code like this and this and this.
X: But I don't like my code looking that way. What gives you the right
to tell me what to do? This just feels wrong. I don't like
unnecessary rules. It's extra work for me. [Whinge, mutter....]
G: But that's dodging the point. You _should_ take all this trouble,
so I can get more work done....
(With heavy exaggeration to get the point across.)
As you say, one route is to have style guides. The other route is to run
'indent' yourself, choosing whatever style will best assist your
understanding, and that of your tools.
Maybe I'm considerably overestimating just what you intend by a style
guide. However, unless questions of New Style are to be resolved like
questions of Old Style (ie. UTSL), it all seems an awful lot of work.
Surely someone has to get 'indent' talking New Style; or document New
Style in all its ramifications; or field New Style questions in a
new-style mailing list. And then there's all the Old Style code that must
be converted. (Which may require, of course, a New Style Inquisitor to
deal with stubborn Old Style code which resists conversion. :)
OK, I'm not entirely serious ... and not really intending to attack the
idea. I think concern about style is decidedly a Good Thing.
If none of these potential objections seem compelling, at least some
implications may have been considered. Personally, I'd be happy to follow
any well-considered set of rules....
--
Robert Nordier
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605291802.UAA00619>