[PATCH 1.12] A coding style for the server

Chase Douglas chase.douglas at canonical.com
Wed Jan 18 11:42:43 PST 2012

On 01/18/2012 04:02 AM, Daniel Stone wrote:
> Hi all,
> So since the list has been fairly quiet and uncontroversial since the
> Ctrl-Alt-Backspace argument, I thought I might throw two comedy patches
> out there and see if they stuck.
> No but seriously though, it's both a) utterly ridiculous and b) faintly
> stupid, that we still don't actually have a coding style.  I honestly --
> honestly[0] -- don't care what the coding style is.  I just care that we
> have one.
> Most of the code we broadly agrees on most things.  Some things were a
> little more split; for instance, cuddling else was only just outnumbered
> by non-cuddling else, and also braces cuddling if outnumbered
> non-cuddling.
> Probably the largest change is that all tabs were expanded to eight
> spaces.  The only argument I've ever heard in favour of having a tab
> hardcoded to eight spaces and mixing tabs and spaces is that a) emacs
> does that sometimes, and b) it makes compilation faster because you have
> fewer bytes to lex.  I honestly don't have much time for either
> argument, and it does provably make editing code harder.
> So, the commit in my coding-style xserver branch is simply the result of
> running this:
> indent -linux -bad -bap -blf -bli0 -br -brs -cbi0 -cdw -nce -cs -i4 -hnl
> -l80 -lc80 -lp -nbbo -nbc -nbfda -nprs -npcs -npsl -saf -sai -saw -nut
> across *.c and *.h in the X server tree.  No more, no less.  The build
> seems to continue to work just fine.  Don't be scared by the -linux;
> it just provides a set of reasonable default options.  Pretty much
> everything else was just done by hand to match what we seem to generally
> do in the server.

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?

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.

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 :)?

-- Chase

More information about the xorg-devel mailing list