From owner-freebsd-hackers Wed Jul 28 16:51:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id C9BC914F9C; Wed, 28 Jul 1999 16:51:24 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA64420; Wed, 28 Jul 1999 16:48:43 -0700 (PDT) (envelope-from dillon) Date: Wed, 28 Jul 1999 16:48:43 -0700 (PDT) From: Matthew Dillon Message-Id: <199907282348.QAA64420@apollo.backplane.com> To: Tim Vanderhoek Cc: Nate Williams , "Brian F. Feldman" , hackers@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG Subject: Re: securelevel and ipfw zero References: <199907282024.OAA03102@mt.sri.com> <199907282042.OAA03370@mt.sri.com> <19990728192425.C318@mad> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message