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>