lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GOP-PROP 3: C++ formatting


From: Trevor Daniels
Subject: Re: GOP-PROP 3: C++ formatting
Date: Wed, 22 Jun 2011 10:06:59 +0100


Graham Percival wrote Wednesday, June 22, 2011 12:30 AM

Another problem is that the scripts/auxiliar/fixcc.py depends on
emacs, but emacs’ formatting changes between versions.


** Eliminate tabs

I’m going to make the bold step of assuming that we will eliminate
tabs in all C++ files. I personally like the idea of tabs, but
from an examination of source code styles (both official and
unofficial) in various projects, I must admit that this ship has
sailed.

+1

Tabs were useful before keyboards had auto-repeating keys, and
still are when laying out tables with fixed width columns.  But the
mixed tabs and spaces required to lay out code with varying
indentations is just a nuisance.

Not everybody has emacs installed, and the C++ formatting varies
between versions. That said, we could probably avoid that problem
by giving a custom .el file with the C++ formatting from whichever
version of emacs we prefer (23.1.1, 23.2, ...?)

Include in build dependencies?  Which version is not important, but
definitely must be fixed.

There’s also the consideration of how much energy we want to spend
arguing about this. My preference is just to say "screw it, let’s
just use fixcc.py strictly". I don’t like tying the code
formatting to a specific text editor (much less one whose
formatting changes with different versions!), but astyle and
uncrustify just don’t seem "there" yet.

Neither do I, but the alternative of defining *precisely* our specific
c++ formatting rules is too horrendous.

** Implementation notes

No plan for how to do this yet; it will be a mess.

Fix a date for the conversion and convert all files in origin/master
on that date.  Publicise it well so developers are fully aware and
can do the same on their own branches.

Any old patches not yet applied will (possibly) break, but they
are known and can be relatively easily fixed, as you say:

somebody applies the patch to the un-indented
source code, then run the indentation tool, then make a new patch,

It doesn't have to be the original contributor who does this as
no code changes are involved.

Trevor




reply via email to

[Prev in Thread] Current Thread [Next in Thread]