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

[Blue Swirl]

On Tue, Aug 17, 2010 at 8:04 AM, Jes Sorensen <address@hidden> wrote:
> On 08/13/10 20:02, Blue Swirl wrote:
>> On Fri, Aug 13, 2010 at 3:22 PM, Miguel Di Ciurcio Filho
>> <address@hidden> wrote:
>>> The existing code that I have touched don't follow the current coding
>>> style guidance, much less all the new recommendations being suggested.
>>>
>>> Although, I do believe that this situation needs to change. If we
>>> agree in a coding style, I would volunteer to be a some kind of
>>> observer to fix and alert people about coding styles mistakes.
>>
>> I fully agree on the need of change and support your excellent idea.
>> There are other ways to solve the problem, but I believe we need more
>> order than more chaos. Perhaps we the QEMU developers should appoint
>> you the Guardian of the CODING_STYLE, and add a rule that no patch
>> shall be committed without your CS-Acked-by line?
>
> I don't think this would ever work, it is begging for trouble relying on
> one person to review all patches for this.

We could have more than one Guardian and also several Vice-Guardians
if there are enough volunteers. Even better, the patch submitters
could do the checking themselves and add a 'CS-Purity-Certified-by'
line.

> While I agree coding style is good since it enforces consistency, there
> are plenty problems with the old rules. For example the rule to demand
> braces around single line in an if statement. It results in more empty
> lines on the screeen, ie lost screen real estate making it harder for
> someone reading the code to get a good overview.

The logic for the braces is explained in CODING_STYLE.

> If we are going to mod the QEMU coding style rules, I strongly recommend
> we look at the Linux kernel rules, while keeping the 4 space
> indentation, rather than trying to adopt things from libvirt.

This was discussed earlier and I suggested switching to Linux kernel
style (without any 4 space exceptions) because of 'indent' support
which would allow for mechanical reformatting. Please visit the list
archives for the discussion and what was the conclusion.