Writing maintainable code [closed]

Answer 1

I already voted up Matt's answer "Good Abstraction" but I wanted to add something.

Documenting it's all about explaining things. I'm all in favor of Doxygen and other automatic documentation tools but crude lists of functions in an API are just better than nothing.

If you want to have your code to be maintanable, describe your solution to the proper level of abstraction and refine that level up to the code so that it's obvious what it does.

Answer 2

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.

Answer 3

• Record assumptions when you make them - two days later you will be taking these assumptions for granted, but the next person who maintains your code won't necessarily make the same assumptions, and will wonder why you did what you did...

• Code for people - the computer will do anything you tell it; code so humans can understand your code - who knows it might be you 6 months from now!

Answer 4

Good abstraction

Answer 5

Good upfront design. Nothing can save a poor design.

Answer 6

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.