On Thu, 2 Dec 2010, Boyce Griffith wrote:
> It looks like Artistic Style's GNU setting more-or-less conforms to the
> libMesh style --- you can invoke it via:
>
> astyle --style=gnu -r $PWD/*.C $PWD/*.h
>
> or possibly:
>
> astyle --style=gnu --max-instatement-indent=79 \
> --min-conditional-indent=0 -r $PWD/*.C $PWD/*.h
>
> This will generate (a ton of) backup files with the suffix ".orig"; these can
> be disabled by adding the "-n" flag.
>
> astyle will also strip out all trailing whitespaces. You can also configure
> it to use tabs or spaces for indentation:
>
> http://astyle.sourceforge.net/astyle.html#_Tab_and_Bracket_Options
>
> It would be easy enough to add a makefile target ("reindent" or "precommit"
> or ... ) to invoke this.
Looks like it expands
functions() { like_this; }
and
functions() {
like_this;
}
into
functions()
{
like_this;
}
which I don't care about either way. Likewise for bumping braces
two characters back in some of our switch statements.
It doesn't indent for a namespace block; most of the time we don't
either but there are exceptions it changed.
It breaks multiple statements onto separate lines, which is a very
thankful change.
It aligns a bunch of multi-line statements that weren't quite
perfectly aligned before.
It strips trailing whitespace from a bunch of lines.
It fixes a bunch of places where thanks to a whitespace typo here or
there we're not following our own loop indentation standards.
Basically, in every line of changes I looked at, astyle made a change
for the better. And it would be nice to get whitespace right the
first time and then never have to touch it again. I've noticed a few
"svn diff" results recently where someone's patch was about 20 lines
of important code I wanted to look at buried in 200 lines of
whitespace improvement I had to sift through.
But the catches are:
There are nearly ONE HUNDRED THOUSAND lines of changes. No way are we
looking over every one of them. Does everyone want to trust that
astyle doesn't break any C++, or that our regression and unit tests
have enough coverage to catch any breakage?
The changes touch every file. Is anyone maintaining their own private
forks of libMesh right now? Because if so, then you'd need to sync up
with the svn head before we used astyle or the fork would get a whole
lot harder to maintain.
This hurts the usefulness of "svn blame". Whoever commits the first
massive set of astyle changes suddenly looks responsible for a whole
lot of code where he merely touched whitespace.
This hurts the usefulness of "svn diff -r A:B" where A is any revision
number before the whitespace change and B is any revision number
after.
All things considered I'm leaning against using astyle... but it would
be much more easy and straightforward than I imagined to use it, so if
others disagree I'll happily be outvoted.
---
Roy
------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Libmesh-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
