On Tue, Feb 14, 2012 at 11:47:52PM +0100, Timon Gehr wrote: > [...] > It does not hurt at all if your code base is more flexible than > necessary. [...]
This needs to be taken in moderation, though. I've had to work with code that was unnecessarily flexible. (I.e., over-engineered.) So flexible, in fact, that almost none of us knew how to use it, and the code ended up deteriorating into a morass of hacks attempting to bypass an overly-general framework that nobody understood. One particularly bad example was that part of the system had a whole hierarchy of database-access classes, intended to replace having to write SQL directly. The problem was that it was so poorly documented, and so difficult to understand, not to mention requiring a instantiating a whole bunch of objects just to do something as simple as "SELECT * FROM some_table;", that eventually people just resorted to writing a function for executing SQL directly, thus bypassing the entire over-engineered mess. And that was only a small part of it. There were other beautifully designed, fully OO, and fully generic classes, that accomplished everything from the most trivial of tasks to the most advanced high-level abstractions. Like the IPC mechanism, for which at one point I had to write code to get through *six* layers of abstraction just to call a single function. One layer of which involved fwrite(), fork(), exec(), and fread(). Such was the result of the original code base being much too flexible than it needed to be. T -- Why are you blatanly misspelling "blatant"? -- Branden Robinson
