> I happen to agree with this point of view; that if a subroutine or > function takes up more than a certain amount of space (usually it is > a 'feeling' that it is inefficient and not a number of lines ;-) ) then > it is going to have more bugs in it that a shorter piece of code. > > I would like to go on record as being a person that is guilty of > producing inefficient subroutines, or code that is bigger than it needs > to be- that is part of the learning process; 3 months from now I > predict that most of the code I have written will need to be rewritten > to use new [better] skills and [more efficient] methods I have learned. > Hopefully, these new skills will extend the reusable parts of my code. > > Feel bad about producing garbage, but accept it happens, > Don't throw anything away, recycle it!
I'm not sure I agree with that. In my own experience, I usually write code three times. The first time involves the elucidation of ideas, trying to get a better handle upon what specifically is needed versus what a particular designer or client THINKS they need. It usually tends to be more linear, can be messy, and is often horribly inefficient. However, it's role is to quantify the domain, and in that respect it can be messy, knowing that you're going to throw it out. The second time through with the code is the organizational pass -- trying to get a sense for commonalities, for classes that may have potential for reuse and for articulating an underlying object model. It is usually much more object oriented, and usually is intended as a way of creating something that can be interacted against to see how well it works with the outside world. This too usually gets thrown away, though a lot more code will make its way into the final revision. The final revision is an optimization pass; find those places where the code can be tightened, ensure a consistent namespace usage, incorporate documentation deep within the code, and fix any points of friction or inefficiencies from the previous revision. This three stage development process doesn't always make sense to non-coders (or to beginners), who often assume that when you write computer code you should only need to write it once. Programming, however, is at its core an iterative process (the cascading waterfall model) toward finding solutions. Before you can find a solution to a complex process you have to understand what the problem is first (which is typically far less obvious than may appear in specs), then you have to explore viable solutions for potential side-effects. Once there, then you can write that final tight, clean code. I've had code that I've written end up being used for years in a wide range of applications outside of those that even I envisioned because I took the time to go through this iterative process, even though initially it caused the client more than a little headache because it took too long by their lights to develop it. Finally, on code reuse: Code reuse is one of the biggest shell games around in programming (sorry for the unintentional pun). Code reuse works fine when you develop code in a modular fashion (black box code with no side effects or hidden default values), and when your framework is relatively flat. However, frameworks have a tendency to become bushy over time and develop hidden interdependencies, especially in those parts of code developed to meet a deadline rather than designed to provide core functionality. Framework architecture development is not, in general, an easy problem, and a fanatical devotion to code reuse can doom a project from the start. Kurt Cagle Author, XQuery Kickstart, SAMS -- Kurt Cagle -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
