Re: [Qemu-devel] Restore consistent formatting

[Blue Swirl]

On Wed, Feb 8, 2012 at 15:23, Anthony Liguori <address@hidden> wrote:
> On 02/08/2012 09:04 AM, malc wrote:
>>
>> On Wed, 8 Feb 2012, Andreas F?rber wrote:
>>
>>> malc,
>>>
>>> Arbitrarily reformatting your files is not okay. If you want a different
>>> formatting, you need to fix checkpatch.pl first to not error on that
>>> formatting in your files.
>>
>>
>> It was always formatter like this (internally consistent), then others
>> added code which made it not so.
>
>
> We do have a mixed style in the audio layer.  I'm not happy about that but I
> also feel strongly that going through and doing a reformat is not a
> worthwhile exercise.
>
> I can also understand the desire to keep things consistent.  But patches
> should always go to the mailing list.  I certainly would have acked such a
> patch FWIW.

Really? First, this would imply that local consistency is more
important to you than global consistency and second, pure reformatting
patches are now acceptable to you (despite previous git blame breakage
reasoning).

What would your reaction be if I declared that CODING_STYLE for
target-sparc/* is Linux kernel one (some pieces could probably be
found which would comply even now to make the precedent case for
argument's sake) and post a reformatting patch to the list?

> I think people get a bit too excited about coding style.  There are much
> more important things to worry about in life than the number of spaces
> before a parenthesis :-)

In general, a coding style is one aspect of development guidance. The
level of guidance can vary, it could be missing, there could be a
loose convention, a guideline or even a iron hard rule. It could apply
differently case by case or globally.

In case of coding style, I'd strongly prefer that the level of
guidance is clear to everyone and it doesn't change very often. As to
the actual content of the guidance, that can never be precise.

In this specific case, CODING_STYLE says nothing about spaces after
function identifiers. However, vast majority of code omits them.
Spaces are used in GNU style, not in K&R or Linux style and I think
QEMU style is closer to them than to GNU style. I'd say this case is
not unlike the previous cases where braces were added to code where
there were none before, so reformatting is going backwards (unless
local consistency is given priority).

Personally I prefer strong, enforced rules to loose conventions but
it's more important to me that everybody in a project plays by the
same rules (or agrees to lack of them), whatever they are. Personally
I also hate GNU style and would prefer that malc would swallow his
pride and reformat audio etc. to match rest of the world, but I
respect his status as taking responsibility for maintaining the audio
layer.

> Regards,
>
> Anthony Liguori
>
>>
>> [..snip..]
>>
>