David Megginson writes: > 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.
I know you are making a point by using extereme wording, but if you are running through the woods, it doesn't hurt to look up once in a while. > 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. Perhaps you misunderstand my position. It's one thing to delete crufty old useless code. However, there may be reasons to keep old code #ifdef'd in. And it certainly doesn't hurt to ask before you delete someone else's old code. > 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. I think there needs to be a balance here. Yes, cruft can get in the way, but code represents knowledge. Code represents experience. Code is the solution to a problem. For myself personally, if I am the author of a section of code, and if I am the one who has to maintain it and answer questions, I *certainly* should have the right to leave comments and hints and 'knowledge' and 'experience' included in that body of code. There may be very good reasons why the author includes it that aren't immediately obvious. If something doesn't make sense, or seems out of place, there's no harm in asking ... perhaps the author will look at the 'cruft' and say oh yea, nothing valuable there, we can axe it. But perhaps the code is there is for valid reasons and it's worth keeping. > 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). Yup, on this point I agree with you completely. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities [EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
