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-ipfw" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907282348.QAA64420>