From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44659) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzmmZ-0000Nf-9e for qemu-devel@nongnu.org; Sat, 03 Sep 2011 05:45:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QzmmX-0005Oi-OK for qemu-devel@nongnu.org; Sat, 03 Sep 2011 05:44:59 -0400 Received: from mail-qw0-f43.google.com ([209.85.216.43]:35962) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzmmX-0005Od-M7 for qemu-devel@nongnu.org; Sat, 03 Sep 2011 05:44:57 -0400 Received: by qwm42 with SMTP id 42so2579606qwm.30 for ; Sat, 03 Sep 2011 02:44:57 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4E5FFDF7.6090504@codemonkey.ws> References: <1314752751.84463.YahooMailClassic@web27003.mail.ukl.yahoo.com> <4E5D8BAA.9010302@codemonkey.ws> <4E5D9570.1030201@codemonkey.ws> <4E5E3789.3010603@codemonkey.ws> <4E5E39DF.3080609@codemonkey.ws> <4E5E4540.5030408@codemonkey.ws> <4E5E5BF3.50801@codemonkey.ws> <4E5FFDF7.6090504@codemonkey.ws> From: Blue Swirl Date: Sat, 3 Sep 2011 09:44:37 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] Add support for r6040 NIC List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Markus Armbruster , bifferos , qemu-devel@nongnu.org On Thu, Sep 1, 2011 at 9:49 PM, Anthony Liguori wro= te: > On 09/01/2011 02:39 AM, Markus Armbruster wrote: >> >> Blue Swirl =C2=A0writes: >> >>> On Wed, Aug 31, 2011 at 4:06 PM, Anthony Liguori >>> =C2=A0wrote: >>>> >>>> On 08/31/2011 09:35 AM, malc wrote: >>>>> >>>>> On Wed, 31 Aug 2011, Anthony Liguori wrote: >>>>> >>>>>> Upper case field names are not okay. =C2=A0If you think coding style= isn't >>>>>> clear, >>>>>> that's a bug in coding style. >>>>> >>>>> Sez hu? Coding style is garbage that should be thrown out of the >>>>> window. >>>>> As for looking, yeah, i'm looking at usb with it's lovely hungarian >>>>> fields, should we stampede to "fix" it? >>>>> >>>>> If the one who's going to maintain the code is fine with whatever >>>>> naming >>>>> is used so be it. >>>> >>>> No. =C2=A0That's how we got into the coding style mess we're in in the= first >>>> place. >>>> >>>> There's no benefit to going through and changing existing code but new >>>> code >>>> needs to be consistent with the vast majority of code in the rest of t= he >>>> tree. =C2=A0It's about overall code base consistency and maintainabili= ty. >>> >>> I agree about importance of consistency, though I'd even go further >>> and reformat globally. New code gets introduced based on copying old >>> code so the pain goes on. >> >> If we reformat globally (big if), > > I'm very strongly opposed to doing a global reformat. =C2=A0It makes it h= arder to > use things like git blame which makes reviewing code difficult. Only for one commit, the commits before and after would still be accurate. There is a tradeoff between benefit of consistent, better quality code and usefulness of git blame. I'd value consistency higher. Inaccuracy is also relative, the reformatting commit is still a commit. > Following a reasonable policy of using a consistent coding style and only > fixing style issues when you touch code for other reasons is well > established (this is the kernel policy) and over time will result in a > reasonably consistent code base. This assumes that all code gets touched every now and then. But in reality some things may never need any changes and then they remain inconsistent. Then bad practices spread from this unchanged base if it's large enough, just like now. By the way, if we assume the opposite (all code is under change), then some time after global reformat git blame would also be accurate since the reformatting commit would be overwritten by the newer changes.