Code maintainability is the synergy realized when we apply all those coding axioms, rules of thumb, principles, etc. It is more art than science. To the extent that we have cooked in an appropriate amount of all these things, the code base is maintainable. Code is not maintainable (yes/no, on/off, either/or) just because you are able to change it (or not).
However, the acid test of maintainability is attempting to change the code. To the extent that the code resists, or doesn't resist, your interaction with it defines it's maintainability.
Maintainability has "abilities". Including, but not limited to
How do we attain these abilities?
Through application of all those software principles and guidelines you've ever or maybe never heard of. For example:
- Good comments
- descriptive variable, method, class names
- Limit methods to no more that a page in length
- Maximize cohesion and minimize coupling
- encapsulate that which stays the same
- encapsulate that which changes
- code layout/formatting guidelines applied consistently
- One entry point only, and one exit point only.
- ... and many, many, more ...
For good maintainability one must consider all of them, all the time, at every level of the code, and apply them in an (not "the") appropriate mix. Further, and I cannot emphasize this enough, no principle works best (or very well at all, perhaps) alone.
Seek Your Roads To Damascus
Several years ago two things came together. A set of programs that were literally unmaintainable and my discovery of Code Complete by Steve McConnell. This book was my bible in rewriting all that worse-than-failure code and the "before and after" comparison of the code was nothing short of revelation.
Find your roads to Damascus. It's a target rich environment.
Read Code Complete
I cannot overstate just how good this book is for learning fundamental software development principles.