Many developers often ask themselves: what exactly is "good code" and why? While there are dozens of principles like SOLID, KISS, or DRY, I have defined my own set of metrics, ranked strictly by their importance.
Here is my hierarchy of code quality:
1. Readability
Code must be easy to read. Period.
Ideally, good code should be understood without documentation and even without deep knowledge of the specific programming language.
The perfect "round code in a vacuum" is when a non-technical manager or a business stakeholder opens a file and understands the logic.
2. Maintainability (Modifiability)
Code should be structured so that it is easy to modify or extend.
This is a crucial indicator, but it relies entirely on the first point. If the code is not readable, it doesn't matter how flexible it is, because you won't know what to change or where to plug in new logic.
3. Correctness (Working Code)
It is logical to assume that code must work—otherwise, what's the point?
However, I intentionally place this below the first two.
- If code works but is impossible to understand or maintain, it is a "time bomb." Any future fix might lead to unexpected side effects.
- On the other hand, if code is currently broken (contains a bug) but is clean, readable, and easy to modify—fixing it takes almost no effort.
4. Efficiency (Optimality)
Good code should consume minimum resources with maximum performance.
While this is important, it sits at the bottom of the list. If your code is optimal but unreadable, unmaintainable, and broken, its performance is irrelevant.
Top comments (0)