[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <48C19E6B.2090505@tmr.com>
Date: Fri, 05 Sep 2008 17:02:35 -0400
From: Bill Davidsen <davidsen@....com>
To: Mike Isely <isely@...ox.com>
CC: Stefan Richter <stefanr@...6.in-berlin.de>,
Michael Krufky <mkrufky@...uxtv.org>,
v4l-dvb maintainer list <v4l-dvb-maintainer@...uxtv.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Mauro Carvalho Chehab <mchehab@...radead.org>
Subject: Re: [v4l-dvb-maintainer] [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2
Mike Isely wrote:
>> If you need this kind of safety measures against errors in future code
>> changes, could it be that you have some general QA problems?
That's always a problem with humans in the loop. I very much agree that
one line or three is far safer against a hasty line insertion than only two.
In my own code I write one if it fits, three if it doesn't. Being easy
to read is good, being hard to misread is better.
>
> One of the points behind a good coding style is that it should encourage
> code that is robust against trivial mistakes. Prefering
>
> if (a) {
> b;
> }
>
> over
>
> if (a)
> b;
>
> I consider to be an example of this kind of simple safety. (And I have
> in the past seen people getting burned from the obvious error of
> sticking a debug printf in between.) ACTUALLY, I'd much, much rather
> prefer
>
> if (a) b;
>
> however checkpatch.pl gets angry about that as well (even though the
> kernel CodingStyle document would seem to actually allow this - it's
> still one statement and since "b" is outside the normal flow then it's
> "something to hide" and should be ok in any case).
>
>
>> (However, why waste time arguing over braces or not?)
>
> Tell that to those who would use checkpatch.pl to gate incoming
> changesets.
>
--
Bill Davidsen <davidsen@....com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists