On Thu, 10 Oct 2002, Lusercop wrote: [ snip the mozilla syndrome description. Lets mention that in other places, see if we can get it cited enough to list it in the OED ]
> I'm curious to know what people's solutions are to this problem, as it seems > to go against code-reuse. I can only imagine that the right answer is some > sort of compromise. This puts me in mind of the extreme programming "you're never going to use that" essay. A 20 character idiom that works on all the platforms you're planning on it running on can either be used directly, or you can call the module, but when someone does some refactoring, they'll find that in the module, apart from the idiom for your platform, there's a lot of branches never taken and variables which are actually constants, within the constraints of your user story[1] This is probably more relevant, the less the function is used in a project. In the grand scheme of things, if you only process soemthing once, then there's a lot of overhead, and making the change later, should it become necessary, is quick. If you're doing something often, or doing several things that a module handles, then the cost of maintainance is much higher if you need to change later, and once the unused code is optimised out on the first compiler parse, calling it repeatedly later isn't costing you much extra. the hatter [1] this is an XP buzzword. I think I'm using it right, but then my P isn't X, so don't count on it.
