Mally wrote:
> I don't suppose its any consolation to know that it seems to have
> been fixed in the version of MSVC that ships with Microsoft Visual
> Studio.NET.
Woo hoo! So (seriously) would folks object to leaving this in place
and requiring a recent MSVC compiler? With gcc, this is a no brainer,
but I accept that folks might not want to have to (erk) buy the thing.
Still, it would make my existence easier (and I'm sure others too) to
just require a standards-compliant tool environment.
Also, does it fix the "no initialization of static const members in
the class declaration" problem? I got bit by that one, too.
> For the present here's a suggestion for you to take or leave as you
> please: If you get into the habit of always using a meaningful name
> for the loop integer, you might find that you end up with a different
> name for the loop variable in the second loop. If you don't
> (i.e. it's referring to the same thing), then maybe you should declare
> it in the outer block anyway.
>
> I know the "i" thing is traditional, but maybe it's time to move on?
Wow, is *this* going to get us into a philosophical debate. I happen
to disagree strongly. The use of simple, terse idioms makes code
*easier* to understand, not harder. When a variable name is
short-lived, all of the code that uses it is on the screen at a time.
Under these circumstances, having a short variable name really is
easier to read. It also has the nice effect of distinguishing "local"
variable names like loop iterators (i) or temporary intermediate
values (float v[3] is a velocity, duh) from "external" ones
(_liftCoefficient, _airDensity).
The "i" thing is traditional because it is an index, and index starts
with the letter I. It is also traditional because mathematitions for
decades have always indexed their summations and tensors with the
letters i, j, and k. Would you object to calling position variables
x, y, and z (which also appears with stunning regularity in my code)?
This comes from exactly the same tradition, and anyone who groks it
should have no trouble with the i notation.
Now, there's a limit to that, of course. Everyone understands:
for(int i=0; i<3; i++) position[i] = 0;
This is less obvious:
for(int i=0; i<_model->numEngines(); i++) {
for(int j=0; j<_model->numTanks(); j++) {
// 80 lines of code, where i refers repeatedly to the engine
// and j to the tank index from which to draw fuel.
}
}
I certainly wouldn't advocate the use of these variable names for that
purpose, and if you check my code, you'll find that I typically don't.
Sometimes, I'll use the i at the very top of the loop to grab an
object pointer to work on, though. That doesn't count. :)
There's an odd assumption in the software engineering world that the
more bytes you put into the name of something, the "better" it is.
Bollocks. Anyone who's ever taken a science class (which certainly
includes anyone competant to work on an FDM) understands that "v is a
velocity, r is a radius, etc..." from context without difficulty. Why
dumb it down to AirSpeed or PropellerRadius and waste all those
columns* for nothing?
* I'm also a big stickler for EIGHTY COLUMN LINES! While we're talking
about unreadable code, try scanning through some of the wide-screen
monsters modern editors are turning out. There's a reason that no
one in print media uses a column more than six inches wide or so. :)
Andy
--
Andrew J. Ross NextBus Information Systems
Senior Software Engineer Emeryville, CA
[EMAIL PROTECTED] http://www.nextbus.com
"Men go crazy in conflagrations. They only get better one by one."
- Sting (misquoted)
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
