> This is where we disagree -- keeping it in makes the code much harder > for new (and existing) contributors to read and understand, gives > false hits when searching for variables and method calls, etc. etc. > With CVS, it's trivially easy to look at or restore old code later if > we need to; I'm strongly in favour of keeping the onscreen code short, > clean, and uncluttered. Unlike the XP people, however, I am a big > supporter of explanatory comments. > > There are parts of FlightGear that have a single, well-known > maintainer (such as YASim or WeatherCM), but a lot of the dead code is > in the well-trodden public corridors of FlightGear, like fg_init.cxx, > main.cxx, etc.
I ran into this problem when looking through FlightGear code in the past. It's hard to keep track of things like: #ifdef xxx ... ... 200 lines of code ... ... #else ... ... 100 lines of code ... ... #endif If the page being shown does not show the #ifdef, it can be really confusing. I can't recall any specific examples of this in the code, but I remember being bitten by this kind of thing a couple of times when perusing some of the base FlightGear code. Elimination of dead code (as we all know, CVS is really good for tracking past changes) and better documentation would be really helpful. We'd like to be better in JSBSim too - we all face this. Jon _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
