From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=47920 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnDbU-000307-CJ for qemu-devel@nongnu.org; Sun, 22 Aug 2010 12:41:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OnDbT-0000jo-44 for qemu-devel@nongnu.org; Sun, 22 Aug 2010 12:41:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38464) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OnDbS-0000jY-U9 for qemu-devel@nongnu.org; Sun, 22 Aug 2010 12:41:03 -0400 Message-ID: <4C715317.5020007@redhat.com> Date: Sun, 22 Aug 2010 18:40:55 +0200 From: Jes Sorensen MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/5] CODING_STYLE amendments References: <4C6A4291.1020105@redhat.com> <4C6A8CD8.2080701@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Miguel Di Ciurcio Filho , Markus Armbruster , qemu-devel On 08/21/10 12:47, Blue Swirl wrote: > On Sat, Aug 21, 2010 at 9:54 AM, Markus Armbruster wrote: >> Unless you mass-convert existing code to your style, tools working on >> source files won't cut it, because reports of the patch's style >> violations are prone to drown in a sea of reports of preexisting style >> violations. There's a reason why Linux's scrtips/checkpatch.pl works on >> patch files. > > Mass conversion would have the benefit that submitters, who use old > code as their reference, are more likely to use the correct style. Problem with mass conversion is that it becomes really hard to track changes for debugging. While it would be nice to get all code to look the 'right way' in a snap, then I think it will cause more harm than good. >> I still think inventing yet another idiosyncratic coding style plus >> tools to enforce it is a waste of time. > > There are historical reasons for the style used in the current code > base. There are also reasons why CODING_STYLE was written like it > stands now. Yes, it's a classic case, there is always the historical side and personal bios for why it was written the way it is. Often this is goes back to personal preference rather than reason :( IMHO it isn't such a big issue what the style is, as long as it is consistent and efficient. The problem with the style we have now is that is is totally inconsistent and has elements making it harder to debug the code, like the braces around single line if statements. I totally agree with Markus that it seems like wasted effort to come up with new tools and having to maintain them when there are good ones out there like the ones from the Linux kernel. Cheers, Jes