I can never forget this post by Mike Hofer in "What's your most controversial programming opinion?" whenever a question along these lines is asked...
Your job is to put yourself out of work.
When you're writing software for your employer, any software that you create is to be written in such a way that it can be picked up by any developer and understood with a minimal amount of effort. It is well designed, clearly and consistently written, formatted cleanly, documented where it needs to be, builds daily as expected, checked into the repository, and appropriately versioned.
If you get hit by a bus, laid off, fired, or walk off the job, your employer should be able to replace you on a moment's notice, and the next guy could step into your role, pick up your code and be up and running within a week tops. If he or she can't do that, then you've failed miserably.
Interestingly, I've found that having that goal has made me more valuable to my employers. The more I strive to be disposable, the more valuable I become to them.
I believe that ideally, both on an individual and a team level, all software should be written to be as easy to pick up as possible. Literally: if the entire team gets food poisoning and dies when going out on a team lunch, the company should be able to hire a new team of developers - and the project should be so clean and well documented that the new people can step in and get to full productivity within a couple of weeks.
So essentially, I think it's more of an "ongoing process" thing than anything you should have to do when quitting. It's not always practical in every single moment, but I believe it's best to work as if you might be dropped off the job at any moment. Code, document, and adhere to processes such that any decent developer could step into your shoes at any time, and not tear their hair out at anything because it's too obtuse.