| [reply] |
The only addition I'd make to what Abigail said is don't change anything until you have to. If, when a change is required, and it affect 2 or more of the scripts, then factor the peice(s) of common code that had to be changed anyway into a module and call it from there.
In other words, only factor stuff that needed changing anyway. If you do it before it needs to be done, a) you will have to modify it again when the needed change comes along; b) you will probably factor stuff that never changes and risk breaking working code; c) worst of all, you will factor stuff now based on the current state of play, that will later need to be changed, but you'll refactor it in such a way that it will complicate rather than simplifying the future requirements.
If it ain't broke don't fix it till it is. When it is broke, try to fix it in a way that makes it easier to fix next time it breaks.
Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
| [reply] |
The question is quick, but there's not enough information to
give a good answer. It all depends. Sure, it's cleaner if you
have just one module to do the task, but is it worth the trouble to modify your existing situation? Do you often have
to change 2 or more of those 6 scripts with the same modification? If so, you might be better off putting it all
together. But then, if it's simple sending out mail, how often
is that going to change? It's not that one is replacing MTA's
with MTA's with a different interface every other week.
Abigail | [reply] |
