Writing maintainable code [closed]

Question

Write it for other people to read. This means a combination of good names, good comments, and simple statements.

Once upon a time memory was scarce and cycles times were slow. programmers were encouraged to write complex single lines of code that did many things. Today memory is plentiful and cycle times are fast. You should write 5 lines of simple code people can follow instead of one line they cannot understand.

Good comments don't have to be long, but they must be helpful.

Also be consistent. Do not change styles in your code. For example don't change naming styles from one section to the next.

Separation of Concerns (each method does one thing) - this stops Spaghetti code.

EDIT: (In response to Ash's comment) The key to maintainability is being able to quickly figure out what the code is doing and how to make changes in order to accomplish a task.

Having the code separated out so that each task is handled by a method dedicated to it makes this a snap.

For instance, if I want to change the way an elbow is bent on software for a robot, having a method named BendElbow makes it a no-brainer where the change needs to be made.

Automated unit tests.

You can slowly change the design of the code via refactoring if you've covered it with automated tests that tells you when it you are breaking existing functionality. Automated tests makes changing code less risky.

Good abstraction

Unit testing hands down. If you unit test your code from the get go then you will have a test suite that you can run to validate the validity of your code whenever you make a change.

Also, when you are writing code with unit test then the methods tend to be smaller since they are easier to test. As well, it should encourage you to make your methods to a single task - again since it is easier to test that way.

Good upfront design. Nothing can save a poor design.

Being on 1st or 2nd level support for the software you just wrote, for a year or two after release.

Trust me, I've been there myself. The "fear" that I may have to maintain or enhance my own code in a years time is always a great motivator for improving maintainability.