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.
There's a lot that can potentially be said about testing, but here are a couple of basic recommendations:
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.
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.