in reply to One Big Script v. Several Small Scripts

Well, the first thing is that you're compiling all the code you don't need every time you run the script. That may or may not be a big deal.

The real issue is something else. I'm willing to bet a paycheck that you have common operations between at least three of those four modes. By breaking them out into four scripts, you find it easier to see the common modes. Then, you create a fifth "script" (called a package) that will contain this common functionality. For example, you need to validate the values to query on for editing, deleting, and listing. Breaking out common functionality is good for bugfixing and maintenance.

Another thing is that you now have a prototypical "add" script. Let's say that you now have a second reason to use an "add" script, for some other DB or some other table or whatever. But, you don't need to re-use your delete script (yet). You can now generalize your add functionality without needing to affect the delete functionality. Maintenance is a lot easier.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

  • Comment on Re: One Big Script v. Several Small Scripts