Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Jul 1999 16:48:43 -0700 (PDT)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Tim Vanderhoek <vanderh@ecf.utoronto.ca>
Cc:        Nate Williams <nate@mt.sri.com>, "Brian F. Feldman" <green@FreeBSD.ORG>, hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG
Subject:   Re: securelevel and ipfw zero
Message-ID:  <199907282348.QAA64420@apollo.backplane.com>
References:  <199907282024.OAA03102@mt.sri.com> <Pine.BSF.4.10.9907281627470.92555-100000@janus.syracuse.net> <199907282042.OAA03370@mt.sri.com> <19990728192425.C318@mad>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

:> The code is *NO* more readable by you re-ordering lines and changes
:> whitespace.
:...
:....
:.....

    Sounds like one of many arguments I've had with various people
    who insist on nitpicking and critiqing to death tiny little
    itsy bitsy inconsistancies that no normal person would care about,
    in a commit that may have taken the author hours of work to make
    happen.

    Gee, someone getting a little hot under the collar?  Why am I not 
    surprised.

    It's one thing when the style's clash badly, quite another when the 
    differences are minor -- things like blank lines (or lack of).

    I'll tell you something, folks, we don't need that kind of aggravation
    when the style differences are minor.

    If people want to insist on nitpicking the code, I recommend a rules
    change:  Such people have to wait a month first, and then offer to make
    the style fix FOR the author rather then badger the author of the
    patch to do it.  After all, the author of the patch is simply trying to
    fix the code, and spending a considerable amount of his own time doing
    so.  The nitpicker, on the otherhand, is acting like a spoiled
    brat who can't be bothered to make the change himself after asking for
    (and almost certainly getting) permission.  After a month, when the code
    in question is less likely to be under active development and the patch
    won't mess up the developers own tracking of the work, the nitpicker can
    offer to make the style commit.

    That strikes me as being quite fair.  

    I also take exception to people trying to use KNF as a defense for
    their nitpicking.  KNF is all well and fine, but it is not possible
    to lock any style in stone for years and years.  You don't get new blood
    into a project that way, and only the few originals left in the crew
    wind up being comfortable with it.  For example, take the evolution of
    procedural prototypes.   When procedures were initially prototyped a lot
    of work went into the __P() style to allow compilation with and without
    prototypes.  But in the last few years a significant portion of the code
    no longer bothers with __P() --- because the code is *expected* to be
    prototyped and *expected* to be compiled with a compiler that understands
    them.  I am sick and tired of standards which are unable to evolve with
    the times and I am sick and tired of people who try to enforce standards
    yet are unwilling to allow them to evolve in any meaningful fashion.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?199907282348.QAA64420>