From owner-freebsd-arch Thu Sep 27 17:38: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by hub.freebsd.org (Postfix) with ESMTP id 9947637B407 for ; Thu, 27 Sep 2001 17:38:01 -0700 (PDT) Received: from laptop.baldwin.cx ([147.11.46.209]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA27074; Thu, 27 Sep 2001 17:36:46 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 27 Sep 2001 17:36:31 -0700 (PDT) From: John Baldwin To: Julian Elischer Subject: Style Wars Cc: Warner Losh , arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [ 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 -- 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