Date: Thu, 27 Sep 2001 18:52:15 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: John Baldwin <jhb@FreeBSD.org> Cc: Warner Losh <imp@harmony.village.org>, arch@FreeBSD.org Subject: Re: Style Wars Message-ID: <Pine.BSF.4.21.0109271841450.65838-100000@InterJet.elischer.org> In-Reply-To: <XFMail.010927173631.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 27 Sep 2001, 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.
In my experience this works best, but with the added thought that
The aim is to get all the names to lign up as much as possible,
so the tab occurs before the name (or "*").
In my personal favourite, if the name is pused out by the
'type' being too long, ta single space is put in..
See 1b) below..
Also you need to leave enough room for comments.
that's why I think that trying to get the name in by
column 24 is a good idea.
Allowing 2 tabs so that composite and simple typed names can line
up is I think not a great problem, but to work it requires that
the tab occure after the type no after the first word..
I menat teh logical grouping is that way.
The first word is not the entire type so it's silly to break
the type 'half-way through'.
> 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;
> };
1b)
struct foo {
int f_type; /* comments start at column 40 */
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;
> };
This is what we have now, and it breaks down when there are composite
types within the structure. It starts to become unreadable.
>
> 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. :)
green is for wimps..
>
> --
>
> 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?Pine.BSF.4.21.0109271841450.65838-100000>