Am Dienstag 03 Juli 2007 13:54 schrieb Thomas Förster (actually it was Tim
Moore :-) ):
> I personally hate underscores or any other indication that a variable is
> a private member, with the rationale that a cursory reading of a
> well-written class will quickly give you that information anyway, but I
> know that the guardians of coding taste disagree with me.
This might work well with only private attributes. But then you get Java's
set/get hell. Combinations like setX(value) { _x = value;}; , x() { return
_x;}; are ridiculous. Why not just declare _x public. If later the need to
change attribute access arises, well then change it LATER. This ensures that
the author of the class at hand has to change all the now forbidden direct
accesses to the attribute. At least he is the one who best knows how to use
the class...
> > Braces
> > ----------
> > Opening braces are on the same line as the preceding statement (function
> > declaration, if clause, etc.). Closing braces follow a newline and are
> > properly indented to align with the block they close.
>
> I mostly agree, except for function definitions. That is just not a very
> widespread style.
The rationale was to save the extra line imposed if the opening brace is on a
line of its own.
Also the 'rule' does not cover oneliners yet (i.e. inline/empty functions).
There all braces should be at the same line.
> Anyway, if you're going to adopt a coding style, you might as well adopt
> one that is familiar to most practitioners of the language, as is the
> one described here. However, it's easy to overestimate the importance of
> a uniform coding style.
I think there is lots of room in the continuum between 'nice to
follow'-guideline to mandatory-forced-rules.
> Experienced developers must adapt to different
> styles in course of their work, and this is not difficult as long as
> individual files or "modules" are written in a good, consistent style.
Unfortunately consistent style is not always the case for FlightGear.
> It is surely in terrible taste to start coding away in a file in a
> different one from the one that already exists there, even if the new
> style is the "official" one.
As is spending precious time to figure out an implicitly defined style. Which
will fail anyway for some obscure 'rules' overlooked ;-) I think
an 'official' style guide might help here as it should be OK to reformat the
whole file to the officially agreed style to ensure consistency. Maybe (to
relax it a bit to personal tastes) this could be done per subsystem or
module, though I'd prefer a single style for FlightGear as a whole.
Thomas
--
PhD Student, Dept. Animal Physiology, HU Berlin
Tel +49 30 2093 6173, Fax +49 30 2093 6375
-------------------------------------------------------------------------
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
