Scripting Best Practices

By: Juliet Kemp
Tuesday, September 2, 2008 10:33:54 AM EST
URL: http://www.linuxplanet.com/linuxplanet/tutorials/6523/1/

Treat Your Variables Right

Scripting languages are incredibly useful for quick-fix scripts. The problem with this is when the quick-fix script is still in place 6 months down the line, at which point the corners you cut because, hey, it's just a short-term fix, come back to bite you. Read on for some best practice tips to make the experience less painful.

(A note: my own scripting languages of choice are perl and bash, but the principles hold across other languages.)

Treat your variables right

When you pass variables into a script or a subroutine, don't just use the default names. Give them real names immediately - it's much easier to keep track of what you're passing in and what you're doing with it. A perl example:

sub concatenate_files {
	my ($firstfile, $secondfile) = @_;
	// rest of the subroutine
}

And while we're naming variables: name them something sensible. Something that'll be meaningful when you read this, say, tomorrow morning before coffee. So, $filelist, not $fl.

Don't hard-code anything. Put all your static values into variables, and collect them all at the top of your script.

#!/bin/bash
EMAIL=admin@example.com
LOGFILE=/var/log/locallogs/mailscript.log

Let Perl Help You

A perl-specific tip: the single most helpful thing you can do for yourself is to use these lines in every script:

#!/usr/bin/perl -w
use strict;

use strict requires you to declare all your variables before (or at least at) their first use. Thus,

my $newvar;
// some stuff
$newvar = 3;  

Comments Are Not Dangerous

Ideally, most of your code should be crystal clear without comments (this is where your variable names come in, for example). But having at the least a comment up top saying what the script does, what input it expects, and what output it provides, will be incredibly helpful in the future.

Within the code itself, if you're doing anything remotely complex, a line or two of comment never goes amiss. While you're at it, consider whether that section would be better as a subroutine.

Testing: do it

There's a lot that can potentially be said about testing, but here are a couple of basic recommendations:

• Do, in fact, test. Even the junk script. Deleting half of a machine by accident is both annoying and embarrassing.
• Test edge cases. What happens if you put in a 0? Or a word instead of a number? What about the wrong number of arguments?
• Test in chunks -- make sure that the first half of the script does what you want it to before you start pouring that output into the second part.
• Use print output to find out what's going on (I confess I am lazy and usually on do this after something has failed to work). Instead of commenting it out afterwards, set a debug variable and only print the debug output if that's true. (This may sound like too much hassle for a temporary script, but you'll be very grateful to yourself when you have to debug it again at a later date.)

Do you really need a script?

Scripts are great. They do many good things, and they're surprisingly extensible. perl is a bit better than shell for anything complicated -- really, if you're writing more than about 10 lines, tops, or doing anything much more complicated than stringing a series of shell commands together, you should probably be using perl (or the alternative of your choice) rather than shell.

But sometimes, what you actually need is a Real Program. If you find yourself spending vast amounts of time on a particular script, or that it's getting steadily larger and more out-of-hand: stop, take a step back, and consider whether you are applying a tiny Band-Aid to a gaping wound. Your scripting language may still be entirely appropriate, but you'll need a different type of structure. Sometimes, the quick-and-dirty fix isn't going to cut it -- it's best to work that out ASAP.

Go forth and practise...

So, that's a quick run over a set of practices that should keep you from cursing your own name unto the seventh generation a few months down the road. Now go forth and implement them the next time you have a problem for which a script is the obvious fix.