Wow. You've gotten a lot of great answers already.
Most of the focus so far has been on what you can do to make your code easier for a maintainer to read, understand, and change. Although these are crucial considerations and I don't want to minimize their importance, talking about them tends to obscure the real point.
The most maintainable code isn't the code that's easiest to read, it's the code that requires the least maintenance.
To use a car analogy, is it more important that the fuel pump be easy to change or that you don't have to do it every weekend?
Your program could be the most cleanly written piece of software in history; it could have perfectly consistent indentation, exactly the right variable names, and just the right amount of well-written accurate comments but if it breaks whenever the environment changes a little it'll probably be more trouble than it is worth.
One reason that this is true is that, the more maintenance that is done to your program, the less maintainable it will tend to become. Fixes are often carried out with an emphasis on speedy completion. It often makes sense to, for instance, toss a temporary variable in the mix rather than determine how to change the algorithm and avoid its use. The result is that the more times a program is fixed, the more cruft it collects. The more cruft, the more difficult it is to make another change next week.
The most maintainable programs are robust and configurable. They validate their input. They error out with informative messages whenever possible. They are coded defensively and thoroughly tested.
There is a lot of worthwhile practical advice that could be given such as to hardcode as few parameters as possible, to check the returns of all of your system calls, or to pay special attention to testing boundary condtions. There are lots of books available that contain lots of this advice and you can learn from them or, more effectively, from experience.
In the end, writing maintainable software is an art. It requires attention to detail as well as the ability to see a bit into the future and guess how users are going to use and abuse your program.
-sauoq "My two cents aren't worth a dime.";
In reply to Re: What is maintainable perl code?
by sauoq
in thread What is maintainable perl code?
by disciple
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |