Scripting Best Practices: Page 3

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.