Date: Fri, 28 Sep 2001 16:31:46 -0700 From: Peter Wemm <peter@wemm.org> To: John Baldwin <jhb@FreeBSD.ORG> Cc: Julian Elischer <julian@elischer.org>, Warner Losh <imp@harmony.village.org>, arch@FreeBSD.ORG Subject: Re: Style Wars Message-ID: <20010928233146.8959B3809@overcee.netplex.com.au> In-Reply-To: <XFMail.010927173631.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote:
> [ moved to -arch ]
>
> On 28-Sep-01 Julian Elischer wrote:
> > well maybe We can come up with a tweek to the standard that we can
> > all agree to...
> > and commit.. It is after all a 'living' document..
>
> Certainly a viable option. I've seen a couple of ideas so far:
>
> 1) Use two tabs instead of one when types longer than one tab such
> as u_int64_t are used.
> 1a) Same as 1) but the tabs after after the type, not just the
> first word.
1b) Same as 1a), but also with 2) for types longer than two tabs.
ie: "struct verylongtypename *foo;"
> 2) Use a space instead of a tab after types longer than one tab like
> we already do for queue macros.
> style(9):
>
> struct foo {
> int f_type;
> struct mtx f_lock;
> const char *f_name;
> volatile int f_int;
> u_int64_t f_64;
> const volatile char f_cv;
> TAILQ_ENTRY(foo) f_link;
> };
>
> 1)
>
> struct foo {
> int f_type;
> struct mtx f_lock;
> const char *f_name;
> volatile int f_int;
> u_int64_t f_64;
> const volatile char f_cv;
> TAILQ_ENTRY(foo) f_link;
> };
>
> 1a)
>
> struct foo {
> int f_type;
> struct mtx f_lock;
> const char *f_name;
> volatile int f_int;
> u_int64_t f_64;
> const volatile char f_cv;
> TAILQ_ENTRY(foo) f_link;
> };
1b)
struct foo {
int f_type;
struct mtx f_lock;
const char *f_name;
volatile int f_int;
u_int64_t f_64;
const volatile char f_cv;
TAILQ_ENTRY(foo) f_link;
};
> 2) is probably the closest to existing style. My personal preference would b
e
> for 3) with an additional note about sorting so that within logical groups of
> members, you would sort the items such that the longest types are first.
> *shrug* I think 4) is just insane. Perhaps if you modified it so that it
> combined types and qualifiers into the same column it wouldn't be so bad
> however.
>
> I like green bikesheds. Specifically dark green, even forest green is pretty
> good. :)
I like 1b) which has some aspects of 2) (the space for overflows)
Yes, 4) is insane. Lets Not Go There. :-)
I could live with 3) but prefer 1b). There is a *lot* of code in 1b) style
in the tree already.
Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010928233146.8959B3809>