On Tue, Aug 17, 2010 at 8:04 AM, Jes Sorensen <jes.soren...@redhat.com> wrote: > On 08/13/10 20:02, Blue Swirl wrote: >> On Fri, Aug 13, 2010 at 3:22 PM, Miguel Di Ciurcio Filho >> <miguel.fi...@gmail.com> 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.
