http://qs321.pair.com?node_id=235735


in reply to Confused.... question on code scalability (reusing functions, etc)

Good rules of thumb:
  1. If you're going to do something more than twice, make it a function
  2. If you're going to use it in more than two programs, make it a module
  3. If doing it even once made your head hurt, throw it in a module
  4. If it has data you don't want to change yourself, make it work from template files
  5. If the code is could be generated from some sort of parameters, use a templating code generator for it
  6. If it feels like a monkey could do it, check the above list to see what you missed

Replies are listed 'Best First'.
Re: Re: Confused.... question on code scalability (reusing functions, etc)
by Anonymous Monk on Feb 27, 2003 at 10:03 UTC

    Nice list :). Any reason for the 'more than twice' rather than more than once? Anytime I find myself rewriting code, I put it in a module and don't wait for the third time. Also:

    If it feels like a monkey could do it, check the above list to see what you missed

    I'd argue that if it feels like a monkey could do it, you're using the right tool ;-). Then again, if it feels like it would bore a monkey, you're definately going about it wrong.

      The reason for "more than two" (really three or more) is that I've found, doing a lot of support programming over the years, that tasks come in three forms--the one-off, the one-off you screwed up and have to redo, and the repeater. (Or the one, two, and many times cases)

      I know the traditional CS counting scheme is "0, 1, or many", and that's more or less true for counts on data instances, but I've found in practice for writing code segments it's more "0, 1, 2, not again!"

      The monkey comment was there to make people realize that, if the job requires no brain at all (we're presuming the monkey isn't smarter than the person doing the task) then a program should be doing the task, and you'd be far more effective writing a program to do the task rather than just doing the task. (Time permitting, of course, and it often doesn't)