From: "David Schwartz" <davids@webmaster.com>
To: "Davide Libenzi" <davidel@xmailserver.org>
Cc: "Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: RE: Coding standards. (Was: Re: [PATCH] [2.5] Non-blocking write can block)
Date: Mon, 9 Jun 2003 14:35:31 -0700 [thread overview]
Message-ID: <MDEHLPKNGKAHNMBLJOLKCELPDIAA.davids@webmaster.com> (raw)
In-Reply-To: <Pine.LNX.4.55.0306091142420.3614@bigblue.dev.mcafeelabs.com>
> If you try to define a bad/horrible "whatever" in an *absolute* way you
> need either the *absolutely* unanimous consent or you need to prove it
> using a logical combination of already proven absolute concepts. Since you
> missing both of these requirements you cannot say that something is
> bad/wrong in an absolute way. You can say though that something is
> wrong/bad when dropped inside a given context, and a coding standard might
> work as an example. If you try to approach a developer by saying that he
> has to use ABC coding standard because it is better that his XYZ coding
> standard you're just wrong and you'll have hard time to have him to
> understand why he has to use the suggested standard when coding inside the
> project JKL. The coding standard gives you the *rule* to define something
> wrong when seen inside a given context, since your personal judgement does
> not really matter here.
>
> - Davide
This is just bad philosophy. You might as well argue that a canvas that's
been randomly pissed on is just as much art as the Mona Lisa. In fact, it's
a worse argument than that because coding styles aim at objective,
measurable goals. Why does consent matter? If some imbecile wants to argue
that it's good to write code that's hard to understand and debug, why should
we care what he has to say? The consent of people whose opinions are
nonsensical is of no value to people who are trying to create rules that
meet their objective requirements.
Coding styles aim at specific measurable goals. Code should be easy to
understand, extend, and debug. If someone argues code should be hard to
understand, maintain, and debug, we just ignore him. We don't care if he
agrees with us or not because his opinion is obviously (and objectively) of
no value.
We can measure, for different coding style, how long it takes to find a
bug. We can measure how long it takes a new programmer to get to the point
that he can contribute to the existing code.
Coding styles are engineering rules. We can validate them based upon the
results they produce. Objective, measureable results.
DS
next prev parent reply other threads:[~2003-06-09 21:22 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-04 0:58 [PATCH] [2.5] Non-blocking write can block P. Benie
2003-06-04 5:53 ` Christoph Hellwig
2003-06-04 14:35 ` Linus Torvalds
2003-06-04 14:58 ` P. Benie
2003-06-04 16:47 ` Alan Cox
2003-06-04 17:57 ` Linus Torvalds
2003-06-04 19:46 ` P. Benie
2003-06-04 19:56 ` Linus Torvalds
2003-06-04 20:48 ` P. Benie
2003-06-11 0:19 ` Robert White
2003-06-04 20:43 ` Hua Zhong
2003-06-04 23:42 ` Russell King
2003-06-04 23:47 ` Davide Libenzi
2003-06-04 21:29 ` Alan Cox
2003-06-04 17:14 ` Hua Zhong
2003-06-04 17:41 ` Linus Torvalds
2003-06-04 18:44 ` Hua Zhong
2003-06-04 18:47 ` P. Benie
2003-06-04 19:23 ` P. Benie
2003-06-04 19:20 ` Linus Torvalds
2003-06-04 17:53 ` Mike Dresser
2003-06-04 15:21 ` Coding standards. (Was: Re: [PATCH] [2.5] Non-blocking write can block) Timothy Miller
2003-06-07 0:12 ` Greg KH
2003-06-07 0:59 ` Alex Goddard
2003-06-09 16:24 ` Timothy Miller
2003-06-09 16:39 ` Jörn Engel
2003-06-09 17:15 ` Davide Libenzi
2003-06-09 17:33 ` Eli Carter
2003-06-09 17:49 ` Richard B. Johnson
2003-06-09 18:07 ` Davide Libenzi
2003-06-09 18:22 ` Jörn Engel
2003-06-09 18:55 ` Timothy Miller
2003-06-09 18:58 ` Davide Libenzi
2003-06-09 21:35 ` David Schwartz [this message]
2003-06-09 22:55 ` Davide Libenzi
2003-06-09 23:21 ` Nigel Cunningham
2003-06-09 21:54 ` Jörn Engel
2003-06-10 18:17 ` Jesse Pollard
2003-06-10 18:41 ` Davide Libenzi
2003-06-10 18:14 ` Jesse Pollard
2003-06-09 23:50 ` James Stevenson
2003-06-09 18:44 ` Timothy Miller
2003-06-09 22:00 ` Jörn Engel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=MDEHLPKNGKAHNMBLJOLKCELPDIAA.davids@webmaster.com \
--to=davids@webmaster.com \
--cc=davidel@xmailserver.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®