Skip site navigation (1)Skip section navigation (2)
Date:      03 Oct 2001 02:46:56 -0400
From:      Randell Jesup <rjesup@wgate.com>
To:        Warner Losh <imp@harmony.village.org>
Cc:        Julian Elischer <julian@elischer.org>, Paul Richards <paul@freebsd-services.com>, John Baldwin <jhb@FreeBSD.ORG>, arch@FreeBSD.ORG
Subject:   Re: Style Wars
Message-ID:  <7fffe858038bd607d1@[192.168.1.4]>
In-Reply-To: Warner Losh's message of "Fri, 28 Sep 2001 17:31:45 -0600"
References:  <Pine.BSF.4.21.0109281714190.72157-100000@InterJet.elischer.org><6bdeb355057b0307d1@[192.168.1.4]>

next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh <imp@harmony.village.org> writes:
>: > I think stating intent, rather than method will reduce a lot of the
>: > quibbling over style issues because people will understand what's bein=
g
>: > aimed for and won't bridle so much over dogmatic rules.
>
>The difficult part in doing intent based rules is that in the past we
>was many style commits back and forth as different people interpreted
>the rules differently.  The more rigid the rules, the more anybody
>will know if things are in compliance.

        I consider these to be different issues.  If you have a purposely
vague rule ("line things up and order them so as to be readable and improve=

understandibility of the code" or some such), then it's really hard to be
"out of compliance".  Someone may disagree over what's more readable, but
it's hard to argue unless it's really screwey.  You could state that when
modifying code, you should attempt to follow the existing style within the
file.  However, I think both a _rigid_ style and/or lots of carping over
style (style commits, major style rework of submissions, etc) merely serves=

to slow down development and reduce interest in submitting patches, with
little if any gain.  I can't say that any of the styles here being
discussed would improve matters much if at all over letting people choose a=

style that promotes understanding that particular bit of code.

        I know for certain that after the experience of getting whacked
over style issues on the one patch I submitted I became much less
interested in submitting patches in the future.  Also, even the excessively=

rigid style dictums for code (as opposed to structs) caused several people
to disagree over whether they were followed or not.  None of the discussion=

was over whether my code was readable; I'm quite certain that a number of 
the changes requested for style(9) issues _reduced_ the clarity of the code=

to anyone (not just to me).

        State intent, and give examples and preferences, but don't spend
immense numbers of hours worrying about style(9) like we do now.

        Stop worrying about rearranging the deck chairs.  There are bigger
fish to fry.  IMHO.

        (Yes, I know my comments here are futile, but I have to try.)
-- 
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team
rjesup@wgate.com
"They that can give up essential liberty to obtain a little temporary safet=
y deserve neither liberty nor safety." 
              -Benjamin Franklin, Historical Review of Pennsylvania, 1759.


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?7fffe858038bd607d1>