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 14:24:15 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Blue Swirl <address@hidden> writes:

> On Sat, Aug 21, 2010 at 9:54 AM, Markus Armbruster <address@hidden> wrote:
>> 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.
>
> Coccinelle depends on OCaml and lots of other stuff, but just I
> installed it with 'aptitude install coccinelle'. These days you can
> also check Linux kernel sources with the included Coccinelle scripts.

Could be "fun" for developers using Windows.  If they exist.

> But depending on Coccinelle for the build wouldn't be nice.
>
>> 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.
>
>> Even a working patch checking tool can only address the last issue
>> (haphazard enforcement), not the other ones.  You may not care.
>
> Which other ones?

Quoting myself:

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

While wasting time for historical reasons is certainly better than
wasting time for the heck of it, it's arguably worse than stopping the
waste.



reply via email to

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