Hi,

On 19 January 2012 06:42, Chase Douglas <[email protected]> wrote:
> Part of the problem of a coding style is the ongoing maintenance. The
> kernel handles this through the check_patch script. This gives rise to
> the following questions:
>
> 1. Should we just go with linux style, so we can use check_patch without
> any modifications?

No - the main problem is that the kernel uses tabs with ts=8 rather
than four-space indents.  While I'm not opposed to it on principle, it
only works for them because they're so aggressive about keeping
functions small and using early return/break-of-control rather than
deeply nested ifs.  Our code would be utterly, utterly unreadable if
formatted to ts=8 while retaining the wrapping at 80 characters.

> 2. If not, will we fork check_patch or make our own?
>
> 3. Who will enforce style? I believe if we have a script we can add a
> commit hook to the git server, but that may be too heavy-handed.

Yeah - maybe it's just something we should try to catch during the
review process, rather than enforce?

> 4. If no one will enforce style, do we want to periodically run indent
> to fix things. Maybe once per cycle after the merge window closes (as
> you suggest here, but I begged for mercy against this time :)?

Heh, sure. :)

Cheers,
Daniel
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Reply via email to