One aspect that doesn't appear to have been covered is what I would term table-driven design.

This involves any kind of coding whereby you can remove pure code, and replace it by a generic loop that runs down an array of values. To extend the functionality of the program, you just have to add another entry to a table, and you're done.

The benefits are that the tables (the user-serviceable parts, if you will), are usually defined at the top of the file, or better yet, in a seperate data file, which means you don't have to grovel through the code to find what you want.

This leads to a second effect, in that if you don't have to grovel through source, possibly adding one too many or too few braces, and getting syntax errors that can be a pain to track down. Or, worse, introducing new semantic errors.

For instance, cascading ifs can nearly always be replaced by a hash lookup.

In a completely different dimension, maintainable code does one thing, and one thing only. For instance, a function that manipulates data and prints it out is doing two things, and that's unmaintable. One day someone is going to need to just manipulate data, and not print it out. At this point they will have to factor out the manipulation code into a new routine, and re-run the the regression tests to make sure they haven't broken anything. (Why are you all rolling around on the floor laughing uncontrollably?)

print@_{sort keys %_},$/if%_=split//,'= & *a?b:e\f/h^h!j+n,o@o;r$s-t%t#u'