Script design: Complexity/generalisation vs. simplicity/specialization (was: Majordomo Utility...)

mjn has asked for the wisdom of the Perl Monks concerning the following question:

I am writing an script which will allow a user with root access to rename a majordomo list and all associated files to a new name. I had gotten almost completely finished with the first try when I ran into a logic problem(moving a file to a new name and then trying to open it using the same ref doesn't really work, in case you were wondering). I sat up at this and thought for a moment: What's the best way to do this?

A given majordomo list has a multitude of files associated with it. Lets take a simple example: mylist.

The files for mylist are these:
/path/to/lists/mylist
/path/to/lists/mylist.config
/path/to/lists/mylist.passwd
/path/to/lists/mylist.resend

/other/path/to/archives/mylist/mylist.0101
/other/path/to/archives/mylist/mylist.NNNN

Along with the files for the list itself the script also needs to change the entries in /etc/aliases. Many of the listfiles themselves also have the listname inside of them. resend for example contains the listname to allow for proper addressing of incoming and outgoing mail messages.

My original script was this: a sub to change the filenames, a sub to move and rename the archives(and their directory), and a sub to change the aliases file, and one last one to modify the contents of files.

My question is this: Should I make the script as exact as possible in the subroutines and what they do or should I spend time making the subroutines very generic and do most of the logical work in the main routine (eg finding the list of files, sending them off to the modify routine then to the rename routine, etc).

I've never taken any programming classes but, rather ironically, my job has come to include a good bit of it. I suppose this is pretty basic concept. My thinking is the latter is prefered as it would allow you to much more easily re-use code and thus bring the overall amount of necessary programming down...

And hey, if anyone has suggestions as to a good way of structure thing as a whole or nifty way to do certain tasks ("renaming" a directory is still elluding me, I can only think to mkdir, move files, and then rmdir), please chime in...

Thanks

_____________________
mjn

2001-05-14 Edit by Corion : Changed title to be more descriptive.

Comment on Script design: Complexity/generalisation vs. simplicity/specialization (was: Majordomo Utility...)

Replies are listed 'Best First'.
Re: (Zigster) How to split code into subs by zigster (Hermit) on May 04, 2001 at 14:02 UTC
To quote another node: Re: Silly code reviews and shift code should be as simple as it needs to be be and no more so. code should be as efficient as it needs to be and no more so. code should be as readable as it needs to be and no more so. code should be as reliable as it needs to and no more so. code should fulfil its technical design brief. Everything comes at a cost. Writting generic flexible code often (but not always) increases it complexity. You have to look at it with a critical cost/benifit eye. Are you likely to need to reuse this code. If the answer is yes there are other applications for this code, then you are probs best off writting a module and pulling the generic stuff out. If the answer is no then write the code to be as maintainable as possible. Look at the points I have bulleted above, consider your priorities and code to those. Re reading your question, I seem to detect a query about how to split up your code. How much to put into subs and how much in the main body. Asside from obvious sub candidates to prevent code duplication; consider the following. A technique often used is to write pseudo code in terms of comments. Then replace each comment with a block of code. I then look at each block of code and consider how valuable the comment is. Does the code describe itself such that the comment is not required, if it does I leave it alone. If the comment is still required then I would move the code to a sub to simplify the main block. This pulls out complex code, allowing for nice partitianing and easier maintenence. I then apply a similar process to all subs. Consider as a rule of thumb not allowing any sub to contain any more code than you can fit onto your screen at a time. Consider the 'main block' as just another sub. ALWAYS KISS ;-) UPDATE Having strolled about pm I noticed: When do you function? tilly's post is excellent ++ Standards for Writing Subroutines These provide some different advice and may be of interest. HTH -- Zigster	[reply]
Re: Majordomo Utility... by Anonymous Monk on May 04, 2001 at 04:55 UTC
Looks like nobody wants to touch this one, so here are my random thoughts. I could probably say something about the importance of the virtues of Laziness and Hubris, but a lot of perl people have probably heard that before. Instead, I'm going to mention the idea of Extreme Programming, especially the principle that simplicity is key. Don't try to build the perfect be-all, end-all program. Just makes something that does what you need, right now, and don't worry about anticipating every possible future need. (Of course, you don't want to hardcode your script to rename "foo" to "bar", but make things like that parameters so that you could concievably use the thing again.) In the back of your mind, remember that you might have to change your code around later. Keeping it simple will make it easier to change when the time comes, and make you less reluctant to do it. Without knowing very much about your script, it's hard to make specific recommendations. Usually, people try to offload as much work to subroutines as possible, keeping the main routine as simple as possible. OTOH, you want to remove as many assumptions as possible from the subroutines so that they'll be useful later. Don't spend all your time twiddling, though. Wait and see where you can improve your program when time tells you what its limitations are. Renaming a directory is easy. Just rename it. That even works in Windows now.	[reply]