Scripting Best Practices

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

That way when something changes
(your email, the mailserver address) and the script breaks, the fix will be
a straightforward two-second job.

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;

The -w flag turns on warnings. This means that if perl sees
something that it thinks looks dubious (e.g. variables mentioned only once),
it’ll tell you so.

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

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

will be AOK, as would my $newvar = 3. But $newvar = 3
without the declaration (or a local declaration) will cause an error.
This is fantastic for avoiding typos or variable name brain-blips: if you
declared $newvar and then use $newcar a few lines down,
you’ll be warned.

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.

This article was first published on LinuxPlanet.com.