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

[Blue Swirl]

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.

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?

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