Roedy Green wrote an extensive guide called: Unmaintainable Code.
"With that in mind, what can this
programmer do to make code more easily
read by humans?"
Answer: Read this guide and apply the reverse of everything it says to your development activities.
Quote from the general principles section:
"To foil the maintenance programmer,
you have to understand how he thinks.
He has your giant program. He has no
time to read it all, much less
understand it. He wants to rapidly
find the place to make his change,
make it and get out and have no
unexpected side effects from the
change.
He views your code through a toilet
paper tube. He can only see a tiny
piece of your program at a time. You
want to make sure he can never get at
the big picture from doing that. You
want to make it as hard as possible
for him to find the code he is looking
for. But even more important, you want
to make it as awkward as possible for
him to safely ignore anything.
Programmers are lulled into
complacency by conventions. By every
once in a while, by subtly violating
convention, you force him to read
every line of your code with a
magnifying glass.
You might get the idea that every
language feature makes code
unmaintainable — not so, only if
properly misused."
While it's a firmly tongue in cheek, it is actually a very useful list (apart from the obnoxious ads) of what to avoid if you actually care about writing readable / maintanable code.