Jeremy outlines the basic principles on writing a maintainable code in much more details that I would.

The principal points are:

  • software change is inevitable
  • planning change with the extensibility points is mediocre
  • separation of concerns (see my previous post on decomposition)
  • orthogonality

The best ready-to-instant-use thing is Maintainable Code Checklist, which I copy here verbatim:

Question Yes comes from…
Can I find the code related to the problem or the requested change? Good Naming, High Cohesion, Single Responsibility Principle, Separation of Concerns
Can I understand the code? Good Naming, Composed Method, The Principle of Least Surprise, Can You See The Flow of the Code?, Encapsulation
Is it easy to change the code? Don't Repeat Yourself, Wormhole Anti-Pattern, Open Closed Principle
Can I quickly verify my changes in isolation? Loose Coupling, High Cohesion, Testability
Can I make the change with a low risk of breaking existing features? Loose Coupling, High Cohesion, Open Closed Principle, Testability
Will I know if and why something is broken? Fail Fast