qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/5] CODING_STYLE amendments


From: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH 0/5] CODING_STYLE amendments
Date: Sun, 22 Aug 2010 18:13:27 +0000

On Sun, Aug 22, 2010 at 4:40 PM, Jes Sorensen <address@hidden> wrote:
> On 08/21/10 12:47, Blue Swirl wrote:
>> On Sat, Aug 21, 2010 at 9:54 AM, Markus Armbruster <address@hidden> 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<tm>' in a snap, then I think it will cause more harm than
> good.

Well, consider for example mass braces conversion to the One Style,
whichever that is. Would it be better to do it in one commit or
multiple commits? If the latter, push all commits back-to-back or just
one at a time now and then?

At the extreme end, we could even convert one statement per commit.
This would make bug hunting with git bisect extremely precise. There
would be a cost of long commit log.

For the patch submitters, wouldn't one shot conversion (with one push,
one or many commits) be less painful?

>>> 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

Fully agree.

> and has elements making it harder to debug the code, like
> the braces around single line if statements.

What's the problem?

> 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.

I also find the tool argument very attractive. No other style has that benefit.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]