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

[Blue Swirl]

On Sun, Aug 22, 2010 at 4:49 PM, Jes Sorensen <address@hidden> wrote:
> On 08/21/10 16:03, Blue Swirl wrote:
>> On Sat, Aug 21, 2010 at 12:24 PM, Markus Armbruster <address@hidden> wrote:
>>> Could be "fun" for developers using Windows.  If they exist.
>>
>> At least OCaml site offers binary download for Windows. I didn't
>> compile Coccinelle myself, so I don't know how much that helps.
>
> I know nothing about Coccinelle, but I did find that yum knew where to
> get it. However, that said, I think we should try to avoid depending on
> exotic tools that may not exist on OSes which may be used by developers.
> What about OSX?

Same thing, binary for OCaml exists. There's none for *BSD or *Solaris, though.

>>>>> 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,
>>
>> Personal preference. I liked Fabrice's style but I also like current
>> style. I would probably like Linux style except for the LISPisms. I
>> don't like GNU or Java style.
>
> My favorite quote from the Linux kernel coding style:
> "First off, I'd suggest printing out a copy of the GNU coding standards,
> and NOT read it.  Burn them, it's a great symbolic gesture." :)
>
>>> 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.
>>
>> But how would you do that? Drop the CODING_STYLE (and accept
>> anything)? Switch to a new CODING_STYLE that is widely appreciated and
>> so all bikeshedding will cease? Enforce current style?
>
> I would suggest we either clean up the existing rule, or switch to the
> Linux kernel style, with the explicit exemption that existing code can
> keep the 4-char indentation, unless the whole file is converted. I'd
> like to avoid a total reformatting of the codebase, but we could look at
> it on a file by file base if it becomes relevant.

Sounds reasonable.