From owner-freebsd-arch Fri Sep 28 16:32: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id E5BA337B40E; Fri, 28 Sep 2001 16:31:46 -0700 (PDT) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f8SNVkM33653; Fri, 28 Sep 2001 16:31:46 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 8959B3809; Fri, 28 Sep 2001 16:31:46 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: John Baldwin Cc: Julian Elischer , Warner Losh , arch@FreeBSD.ORG Subject: Re: Style Wars In-Reply-To: Date: Fri, 28 Sep 2001 16:31:46 -0700 From: Peter Wemm Message-Id: <20010928233146.8959B3809@overcee.netplex.com.au> 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 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