Code Quality
I started trying to explain code quality as prep work for something I'm doing later this week.
I ended up with this:
What is code quality?:
- Readability. Anyone should be able to sit down in front of your code and figure out what it's doing without your input.
- Maintainability. It should be easy to make changes to the code without breaking it. It should be easy to figure out what to change.
- Robustness. It should survive reasonable unexpectedness.
- Performant. It should execute with reasonable speed and use a minimum of resources.
- Elegant / Beautiful. The code should feel clean. You should not feel that you made a sacrifice.
This is also ordered. Yes, I consider readability more important than maintainability. Unreadable code is rarely maintainable code; unreadable, maintainable code is trivial.
So I got curious, and naturally:
http://stackoverflow.com/questions/405243/how-do-we-define-code-quality
I don't consider requirements to be a valid measure of quality. You can have quality code that fails and you can have ugly code that works. Both are fine. Ship the latter. Beat yourself up over it. Do better.
I get stabby when people measure quality in terms of non-negativity. Quality is never about not doing things. Meeting requirements is non-negativity. Exceeding requirements is a positive mark, but (1) that's a measure of quality in your attitude, not your code and (2) excess can be bad.
And yes, in the real world, there are always trade-offs. The point of the list is to have grokkable ideals to aim at.
...
Also, I don't consider testability to be a good goal. However, I'm being argued down on that, so it's kinda malleable.
I ended up with this:
What is code quality?:
- Readability. Anyone should be able to sit down in front of your code and figure out what it's doing without your input.
- Maintainability. It should be easy to make changes to the code without breaking it. It should be easy to figure out what to change.
- Robustness. It should survive reasonable unexpectedness.
- Performant. It should execute with reasonable speed and use a minimum of resources.
- Elegant / Beautiful. The code should feel clean. You should not feel that you made a sacrifice.
This is also ordered. Yes, I consider readability more important than maintainability. Unreadable code is rarely maintainable code; unreadable, maintainable code is trivial.
So I got curious, and naturally:
http://stackoverflow.com/questions/405243/how-do-we-define-code-quality
I don't consider requirements to be a valid measure of quality. You can have quality code that fails and you can have ugly code that works. Both are fine. Ship the latter. Beat yourself up over it. Do better.
I get stabby when people measure quality in terms of non-negativity. Quality is never about not doing things. Meeting requirements is non-negativity. Exceeding requirements is a positive mark, but (1) that's a measure of quality in your attitude, not your code and (2) excess can be bad.
And yes, in the real world, there are always trade-offs. The point of the list is to have grokkable ideals to aim at.
...
Also, I don't consider testability to be a good goal. However, I'm being argued down on that, so it's kinda malleable.