[cmake-developers] CMake code style

[Alan W. Irwin]

On 2010-09-21 21:33+0200 Michael Wild wrote:

> IMHO the style should be checked using a commit-hook, and if it
doesn't match, the commit should be refused. The reason why I prefer
this over periodically run cleanup-scripts is that these scripts make
the "blame" operation nearly useless.

That's a feature not a bug.  :-)

Seriously, I guess it really depends on the corporate culture of
Kitware.  If they are determined that no commit should ever have a
style fault it sounds like your idea is a good one but at the expense
of making it more difficult to commit.  If they are more relaxed about
it, and don't mind the occasional variation in style on first commit,
then aperiodically running a cleanup script is the answer.

That more relaxed style approach has worked well for the all-volunteer
PLplot project where you positively want to encourage your developers
to develop rather than focusing too much on style.  Of course, our
developers will tend to follow the PLplot style in any case because a
consistent PLplot style example is right in front of them when they
modify an existing file. Furthermore, the PLplot developers are
encouraged to run the style cleanup script before they commit their
work, but if they forget to do that it is no big deal because I am
happy to run that script every week or so to enforce a consistent
style. I think it helps politically that I have no style axe to grind
except that I want it to be consistent.  So to force style consistency
I tend to run the script (although others are encouraged to do so as
well), and others make the style decisions that go into the uncrustify
configuration file that we use.

> Similarly, I loath "whitespace errors" (inconsistent indentation,
mixing of tabs/spaces for indents, tabs for alignment, trailing
whitespace), but I'm also against fixing them for their own sake. I
rather keep them until that particular line/block needs to be changed

I would still advocate running a style cleanup script once and making
a giant commit for all those style changes.  Then you are done with
all style cleanups in the current codebase which has the big advantage
of creating a consistent style for your codebase as an example for all
your developers.  Then you can move on to the problem of what to do
with future commits following an approach similar to one of the
scenarios above.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________