Jim Wilson writes: > From where I sit, I'd have to agree more with David. There should > be no cruft left in the code that gets committed. This doesn't > mean individual developers can't keep it around on there local > drive, but once something is good enough to commit it should > contain working code and nothing else. Critical information can > always be kept in comments, but ifdef'ed or commented out code is > very distracting. For here on out I hereby give anyone permission > to hack out any dead, commented out, or useless code that I submit > to the project. You don't need to ask. :-)
We'll keep this on file. Same goes for me, by the way. Here's something that might help -- perhaps coders who want to keep old code around and visible could paste it into a separate file, like foobar.attic for foobar.cxx. That way, it would still be visible and easy to find. Personally, I think that's overkill, but it's an alternative for people who don't quite trust CVS to preserve their thoughts for posterity. > On planning ahead: Back when I studied systems analysis 20 years > ago, planning ahead was everything. Hardware price/performance, OO > design, and networks have changed all that. These things are what > make requirements so unpredictable these days (and systems so > flexible). How many distribution software designs of the early > nineties anticipated web based e-commerce? But now as the business > world becomes increasing internetworked, requirement cycles measure > in weeks and months, not years and decades. It is hard to break > old habits though. On tech projects where I've been involved (ranging from $25K to over $50M), I figure we lost $10-$100 for every $1 we saved anticipating future needs. Jim's right -- people are just too stupid to guess the future (if you want a laugh, read the analysts' predictions on Yahoo! finance every morning before the markets open, and compare them with the market close after 4:15 EST -- it boggles my mind that they analysts be wrong *more* than 50% of the time). Planning ahead is OK, but C++ code and interfaces are not the place to do it. What you want is a short, 1-3 page roadmap document saying "here's what we might do in the future and here's how we might do it." There's no point writing more than a few pages unless you want to give up any pretence of writing non-fiction. Perhaps we should stick three files in every code directory: a README file, explaining what the code in the directory does, a PLANS file, where we can put ideas for future interfaces, and an ATTIC file, where we can paste old code we might need again some day. When people send patches, they can send updates to these files as well. I'll volunteer to start the README files myself, if no one objects. Don't expect more than ten words each. All the best, David -- David Megginson [EMAIL PROTECTED] _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
