Alex Perry writes: > > Fair enough. I certainly overengineered props.[ch]xx, in anticipation > > of all kinds of sophisticated stuff that people never bothered doing. > > I've been learning, slowly, from the XP people to build only for today > > (all my training previously was to anticipate future needs, and it's > > hard to let that go). > > It's nice to have a concept that can support all that stuff if/when we > have an excuse to make use of it. Put the methods and stuff into the > header file, with a comment that they are not implemented yet, and have > the implementations break if used. That makes it easier to have backward > compatible code when the snazzy features get added.
Yes, except that I think we're paying a price with a couple of levels of unnecessary indirection and with code that no one but me can understand. I'd like to keep most of the user-level stuff intact, but to remove the developer-level stuff we're not actually using and reduce the number of layers. One thing that has impressed me about Andy Ross's code over most of the rest of FlightGear (including any of my own contributions that I haven't looked at for a few months) is that I was able to understand most of his code immediately. Part of that is because he uses good, clear design patterns, but a lot of it is because he is a good practitioner of worse-is-better: when in doubt seems to err on the side of leaving stuff out rather than putting it in. >From my experience both on open source and on large commercial projects, I've come to agree entirely with the XP people on certain points: 1. Never write code that you don't need right now, and never make a design more complicated than it needs to be for today. On average, it's cheaper to add one new feature later, when it's needed, than to waste time and obfuscate code by adding twenty new features now purely on spec. 2. Deleting code is as important as writing code. Never leave old code lying around. Instead of commenting or #ifdef'ing stuff out, delete it. If no one's using a particular class or method any more, delete it. If only a class or method is used in only a couple of places, try refactoring the code to use a different approach then delete the class or method. Curt and I disagree on the second point but try (most of the time) to respect each-other's opinions. Personally, I believe that (especially with CVS and ediff-revision in XEmacs for restoring old stuff) the cost of leaving in a lot of commented-out old code is painfully high -- it makes the code hard to understand and maintain, so people tend not to touch it until either something breaks or the whole development stalls. We have to try to write code that a new developer can understand the first time through, and that means keeping it short and simple and avoiding indirection and subclassing wherever possible (the last point shouldn't be controversial, since modern OO design frowns on excessive subclassing anyway). For the record, I don't agree with the XP people on team programming or the unimportance of documentation. All the best, David -- David Megginson [EMAIL PROTECTED] _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
