On 6/13/07, Durk Talsma <[EMAIL PROTECTED]> wrote:

In the past, we have had discussions on the use of autoformatting tools,
but
the general consensus was that most tools, in particular "indent", did not
handle C++ (as opposed to plain old 'C') very well. However, that
discussion
was years ago, and I found this to be a good opportunity to start looking
for
a decent indentation tool again.


In the past, yes indent did not correctly handle C++ code.  It did a few
things ok by chance, but messed up on many things.  At the time we evaluated
this, astyle handled C++, but did some things I considered unacceptable, and
there was little ability to turn on/off various formatting features like you
could with "indent."

I came across this little program bcpp, which I referred to in the beginning
of the thread. After some tests, I sent out the email that started this
thread. Then I ran bcpp on a copy of AIAircraft.cxx, and was -in general-
very pleased with the new consistency.


I haven't had a chance to look at this one, but for what it's worth, the
most useful "reformatter" I've seen so far is "emacs" indent-region
command.  The biggest hurdle by far for me understanding code is
inconsistant and sloppy indentation.

In light of the this, I would like to reopen the discussion again. In the
past, it was decided not to use beautifiers, because of their inability to
handle C++. But it seems like those days are gone. The tools that I did
check
out seem to be doing a good job on C++ code, and and can configured quite
easily to do formatting into an acceptable style. For FlightGear, it seems
like this would be Kernigan and Richie, using 4 spaces. (K&R/4) for each
level of indentation. I still believe it's too early, to go with a general
recommendation in favor of using a beautifier. However, I don't really see
anything wrong with occasional use of one of these tools done by one of
the
regular committers, in particular when it's done in combination with a
careful evaluation of the results and when circumstances favor such a
reformatting.


I'm still very nervous about enforcing some "automated" formatting style on
the entire code base.  There are some implications here that need to be
considered ... for instance, how do we handle JSBsim or other code
dependencies that we pull in?  There are some very skilled coders
participating in this project who have very specific coding styles for very
specific reasons.  I'm not sure I want to impose some automated format on
them ... it could be a major hindrance if they have to deal with matching a
formatting style they don't like or have specific legitimate problems with.

Occasionally there are particularly hideous chunks of code that are
screaming to be fixed up, and for those, an automated tool is probably as
good as anything.

But on the whole, for the entire project, once we get beyond the initial
"sounds like a good idea" effect and you start looking at all the
implications, I start to wonder if it would be more of a pain to enforce one
single style for not all that much gained.

Curt.
--
Curtis Olson - University of Minnesota - FlightGear Project
http://baron.flightgear.org/~curt/  http://www.humanfirst.umn.edu/
http://www.flightgear.org
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to