Handing maintenance over to someone else is always a difficult thing to do smoothly. My focus would be on making the code as readable as possible.
Part of this is consistency of style, but the part I like to focus the most on is making small chunks of code (handlers are a must) that use descriptive names that read fairly well. Sometimes this means tearing out a gnarly piece of code and putting it into its own handler so you can replace a that big chunk of code with a simple call to a handler with a nice descriptive name.
Descriptive names are useful for variables, too. Any significant variable should also have a descriptive name. Short variable names like i, o, etc. are usually OK for temporary use in very simple contexts, but I try to avoid them in more complicated situations. The classical progression of nested loop variables from i to j to k is cute, but unless the loops are processing something like a multiple-dimension array, they are not terribly descriptive names.
There is a quote from Structure and Interpretation of Computer Programs related to all this that I like very much:
If things are still not clear enough after making the code as readable as possible (sometimes there are things like performance constraints that prevent structuring the code in the most readable way), then some documentation might be useful.
Assumptions are always good things to document. Both the small assumptions and the large assumptions are important to document. The small assumptions that pieces of code make are things like “the list will never be empty”, and “because of the above if statement, we know the extension will always be png”. The large assumptions that scripts or applications make are things like “the work directory will contain only the files that need to be processed”, “all images will be png format”, “requires Mac OS X 10.5 due to .”, and “developed and tested only on Mac OS X 10.4.11 with Mail 2.1.2 and Address Book 4.0”.
Also, the overall flow of the program and its objectives are also good to document.
Once the code is readable and the documentation is ready, it would be a good idea to have one of the people that might have to modify the program later read through it and give you feedback on any parts that were not clear. Sometimes it is not possible (the person has not been identified or hired yet, etc.), try to get at least one “third party” to review the code and documentation. It is best when the reader has similar skills and experience to the people you think might have to do the work in the future, but anyone that is not the original author can bring a valuable, fresh perspective to the review.