Re: [Qemu-devel] [PATCH] Add support for r6040 NIC

[Blue Swirl]

On Thu, Sep 1, 2011 at 9:49 PM, Anthony Liguori <address@hidden> wrote:
> On 09/01/2011 02:39 AM, Markus Armbruster wrote:
>>
>> Blue Swirl<address@hidden>  writes:
>>
>>> On Wed, Aug 31, 2011 at 4:06 PM, Anthony Liguori<address@hidden>
>>>  wrote:
>>>>
>>>> On 08/31/2011 09:35 AM, malc wrote:
>>>>>
>>>>> On Wed, 31 Aug 2011, Anthony Liguori wrote:
>>>>>
>>>>>> Upper case field names are not okay.  If 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.  That'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 the
>>>> tree.  It's about overall code base consistency and maintainability.
>>>
>>> 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.  It makes it harder 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.