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: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 0/5] CODING_STYLE amendments
Date: Sat, 21 Aug 2010 11:54:11 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Blue Swirl <address@hidden> writes:

> On Fri, Aug 20, 2010 at 6:44 PM, Blue Swirl <address@hidden> wrote:
>> On Fri, Aug 20, 2010 at 1:47 PM, Markus Armbruster <address@hidden> wrote:
>>> Anthony Liguori <address@hidden> writes:
>>>> To be perfectly honest, we have enough hard problems to solve in QEMU.
>>>> We're spending a lot more time on coding style than we probably need
>>>> to :-)
>>>
>>> In my not so humble opinion, that's because the current CODING_STYLE is
>>> idiosyncratic, widely disliked (follows from idiosyncratic pretty much
>>> inevitably), widely violated by existing code, and only haphazardly
>>> enforced for new code.
>>
>> I think Coccinelle could help us here, it can check for some of the
>> CODING_STYLE issues. We only need to include it to our build system
>> and add git hooks if possible. It can also perform mechanical
>> conversions (if desired).
>
> This Coccinelle script seems to do the job:
[...]
> There are some formatting issues though, I get changes like:
> -    for (i=0; i<5; i++)
> +    for(i = 0;i < 5;i++) {
>
> Reformatting the expressions with more spaces is nice, but removing
> the spaces between 'for' and '(' and especially after ';' is not.

Please make sure that patch submitters can easily check their patches
with your tool.  Depending on coccinelle isn't a problem for me, but it
may well be for others.

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.

Even a working patch checking tool can only address the last issue
(haphazard enforcement), not the other ones.  You may not care.

I still think inventing yet another idiosyncratic coding style plus
tools to enforce it is a waste of time.



reply via email to

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