| [ << Administrative policies ] | [Top][Contents][Index][ ? ] | [ LilyPond grammar >> ] | ||
| [ < GOP-PROP 2 - mentors and frogs ] | [ Up : Policy decisions (finished) ] | [ GOP-PROP 4 - lessons from 2.14 > ] | ||
14.6.4.3 GOP-PROP 3 - C++ formatting
Speaking academically, C++ code style is a "solved problem". Let’s pick one of the existing solutions, and let a computer deal with this. Humans should not waste their time, energy, and creativity manually adding tabs or spaces to source code.
We have modified fixcc.py to use astyle, along with extra
regex tweaks.
- the final script will be run blindly on the lilypond source code. We will accept whatever formatting the final version of this script produces, with no manual tweaking.
-
patches which have been run through this tool will not be rejected
for style reasons. Any code formatting “desires” which are not
enforced by
fixcc.pywill not be considered grounds for rejecting a patch. -
for now, this style will not be enforced. It is not cause for
concern if patches which do not follow the formatting done by
fixcc.pyare pushed. From time to time, Graham will run the formatter on the entire code base, and commit the resulting changes.In a few months, we will tighten up this policy item (with some sort of automatic processing), but that is outside the scope of this policy item and is a matter for later discussion.
- after the proposal is accepted, we will leave some time for existing patches to be accepted and pushed. The script was run on the source code on 2011 August 01.
GNU code
LilyPond is a GNU project, so it makes sense to follow the GNU coding standards. These standards state:
We don’t think of these recommendations as requirements, because it causes no problems for users if two different programs have different formatting styles.
But whatever style you use, please use it consistently, since a mixture of styles within one program tends to look ugly. If you are contributing changes to an existing program, please follow the style of that program.
(http://www.gnu.org/prep/standards/html_node/Formatting.html)
With that in mind, we do not think that we must blindly follow the formatting given by the currrent version of Emacs.
Implementation notes
We can avoid some of the style change pollution in git history by ignoring whitespaces changes:
git diff -w
Discussions
| [ << Administrative policies ] | [Top][Contents][Index][ ? ] | [ LilyPond grammar >> ] | ||
| [ < GOP-PROP 2 - mentors and frogs ] | [ Up : Policy decisions (finished) ] | [ GOP-PROP 4 - lessons from 2.14 > ] | ||