Date: Thu, 27 Sep 2001 17:36:31 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Julian Elischer <julian@elischer.org> Cc: Warner Losh <imp@harmony.village.org>, arch@FreeBSD.org Subject: Style Wars Message-ID: <XFMail.010927173631.jhb@FreeBSD.org> In-Reply-To: <Pine.BSF.4.21.0109271735040.65838-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[ 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.
2) Use a space instead of a tab after types longer than one tab like
we already do for queue macros.
3) (A new one) Just axe the tabs directly and change to always using
a single space. Qualifiers like const and volatile reduce the
usefulness of the tab as do long type names.
4) Have one column for qualifiers if any are present, one column for
types and one for names, with each column separated by enough tabs
such that each column lines up.
Here's a sample struct in style(9) and the 3 listed ideas:
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;
};
2)
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;
};
3)
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;
};
4)
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 be
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. :)
--
John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
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?XFMail.010927173631.jhb>