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 __________________________ _______________________________________________ cmake-developers mailing list [email protected] http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
