Structuring fairly small scripts

Question

I write alot of fairly small perl scripts. They will range from 10 lines to maybe 1,000 lines but the median size is probably only around 100 lines. When I start writing the script I tend to break things up into chunks and create subroutines. What happens is I end up writing alot of scripts that look something like

sub mkdir {
    ... directory testing logic ...
    ... mkdir ...
}
sub createFile {
    ... check for directory ...
    ... try and create the file, exit if failure ...
}
sub somethingElse {
    .... do stuff with the file that was created ...
}
sub yetAnotherThing {
    ... do even more stuff ...
}

&mkdir;
&createFile;
&somethingElse
&yetAnotherThing

This has always looked very odd to me. I like that it ends up being modular and I can easily comment out certain tasks but I'm not certain it's the best way to structure such small programs.

My questions are:

Does anyone have any specific reason why I shouldn't structure scripts in this manner? I don't see many other people doing this so it feels like perhaps I'm doing something wrong.
Can anyone suggest a better way to structure smaller scripts? Should I just skip creating subroutines at all and write out what I want my script to do in order? Am I overthinking this? :)

Thank you!

Nothing wrong with that, make functions [loosely coupled](http://en.wikipedia.org/wiki/Loose_coupling) so you can put them in `.pm` and reuse them as much as possible. — mpapec, Oct 25 '13 at 06:58
Sidenote; drop `&` in function calls, and use parentheses http://stackoverflow.com/a/8915304/223226 — mpapec, Oct 25 '13 at 07:02

score 3 · Accepted Answer · answered Oct 25 '13 at 06:55

What you're doing is correct and it's considered good practice in programming. It's called functional decomposition - you break down your tasks into smaller functions.

In fact, in the industry what tends to happen is people start out writing large chunks of inline code and then later when that becomes unmanageable start to refactor out the code to become more like what you're doing.

Look at projects in CPAN for example. Most of them are broken down to small functions. In fact, most of them are further broken down into modules of related functions.

This is a good first step. The next step is to write .pm files of related functions that you can use in your code. Next step after that is to write object oriented code.

I'd like to note that advocates of a style of programming called "clean code" recommends that each function should have no more than 5 lines of code. It sounds absurd but when I look at all the code I've written some of what I consider the best examples of my own work more or less obeys that rule. — slebetman, Oct 25 '13 at 06:57

score 2 · Answer 2 · answered Oct 25 '13 at 06:58

Your approach looks sensible enough to me, and I do see scripts like it elsewhere.

Some of your approach might now be a comfortable habit that you have grown into and would deserve a re-think and a deliberate try for something higher level. For a start, how many of your scripts contain pretty much the same 5 directory and file-handling logic subroutines? There's a good chance you could either:

Make a concerted effort to find a CPAN module that would make those routines shorter or not required.
Write your own modules to contain code shared between your scripts.

Both these things will allow you to become more efficient, and as you seem to be writing a lot of these scripts, that's worth pursuing.

Structuring fairly small scripts

2 Answers2