Re: GOP2-4 - C++ and scheme indentation (probable decision)

[Jan Nieuwenhuizen]

Graham Percival writes:

> ** Proposal summary

I would like to see it something like this, and have something like
this added to the documentation/archive:


All code is indented and formatted to the GNU coding standards, See
*(Standards)Formatting: .

This means that Emacs' indent-region leaves indentation in tact.  If you
are using another editor, such as Vim, Eclipse or Kate, select GNU style
indentation.

C++ will remain as-is, using astyle 2.02 (not astyle2.02.1) with
scripts/auxiliar/fixcc.py

Scheme will be indented with a yet-to-be written
scripts/auxiliar/fix-scheme.sh, which does the same thing as Emacs.

We do not use tabs for indentation in source code.  Because this is an
additional requirement that would mess-up the indentation of most other
GNU projects, we will add a .dir-locals.el file holding

         ((nil . ((indent-tabs-mode . t))))
                  (fill-column . 80)))

to all directories that
hold source code, notably lily/, flower/, scm/ and python/*.

> ** Motivation
>
> New contributors sometimes struggle to follow our indentation and
> code style – this is especially difficult when parts of our
> existing source code doesn’t have a consistent style. This is
> problematic... we want new contributors to be struggling with the
> lilypond architecture, not playing games in their text editors!

OK.  Again, this is why, in the Proposal above, I make it very clear
what the standard is, so that this should not be an issue.

> Emacs is not an answer; nobody wants to install 50 megabytes just
> to format scheme code. Especially when a standalone tool could do
> the job in probably less than 10 Kb.

I object to this nonsense.  Your reasoning is flawed.

We are a GNU project.  As such we use GNU coding standards.  Emacs is
the GNU project's editor that, intended to make the programmer's job the
easiest.  As such, Emacs takes most worries about indentation away by
automating it.  By default, it does so according to the GNU standards.

Any time wasted on discussing something that is already set in stone is
a waste of time.  Upholding and documenting gratituous differences that
can be removed is a waste of time.

Anything that can be automated, that otherwise would require manual
intervention or attention, should be automated.  I do not care if the
tool is 50MB to install.  I would not care if it is 200MB to install.  I
would even personally compensate the top 20 LilyPond contributors for
the disk space they require to store Emacs, for that matter.  About
1cent at current hard disk prices, possibly 4cent when using SSD.

Everyone running a project or working on a project should strive to
automate away anything that can be automated.  Even if the time gained
in the short run equals the time taken to automate it, it is probably a
win.  Automating something is repeatable and executable documentation
and more fun than repetitive manual tasks.

If things can be simplified, if dependencies can be dropped, if things
can be sped-up, even better.  Of course, automating is not an end in
itself.  The idea is that the accumulated time gain will benefit the
project.  This is most obviously where astyle comes in.

Of course, if a similar result can be obtained by a simple tool such as
astyle, that's perfect.  It's a huge win.  But the argument: we won't
automate this and will document deviating manual procedures that will
require all [GNU] hackers to manually jump through these hoops because
automating it requires a 50MB tool and in theory the tool could be much
smaller...isn't that just silly?

-- 
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl