What does code quality mean to you?

Not really a post, but a discussion. What does code quality mean to you?

Comments

[Kate (she/her)]

Great question! I'm sure there's a lot more but at the top of my mind:

• Easy to read and understand. This includes using variable names and methods that make sense. Also, when code is getting long and complex, abstracting out some logic to helpers or separate modules...
• Well-tested!
• Consistency! Does the code fit in with the rest of the codebase? Obviously there are exceptions to this such as when transitioning away from xx to yy, but if there's some sort of agreed upon guideline around styling (linters can help) or where things belong in terms of organization.
• Being up to date on dependencies.

[Alain Van Hout]

To me, code quality means any changes to code that improve predictability and reduce the amount of effort needed to make future changes. Generally speaking, that's done through rules of thumb (use clear variable names, limit method length, use unit tests), which on average will have a positive effect on the aforementioned predictability and effort.

From another viewpoint, code quality is one facet that helps is increasing maintainability (others are good communication, proper requirements, reflecting on architectural tradeoffs, etc).

[Michael Levan]

Yeah, this is a good point. "Increasing maintainability" is definitely crucial. Making the code easier to read ultimately makes it easier to maintain as well. Good one!

[Alain Van Hout]

Thanks 😁. I think that's an important and generally overlooked point: if maintainability is the goal, and code quality just a tool (and not the actual goal), then you (often) need to decide on what you need to spend your time on to optimally increase maintainability. When you need to spend twice as much time to get that code quality from 90 to 95% (figuratively speaking), then chances are that that time is better spent on other improvements that have a higher impact on maintainability.

[Jeremy Forsythe]

1. Is the code readable?
2. Does the code do what it is supposed to?
3. Is this the simplest solution (can you remove code or complexity)?
4. Are functions pure and testable?
5. Are concerns properly separated?
6. Are files / modules properly separated and organized?
7. Has static analysis been run? (linting, dependency audits, etc.)
8. Can you explain what it does / the design / the architecture in plain and simple terms? (while this seems unrelated to code, it can be an indication of too much complexity)
9. Do names say what they are/do? Are arrays pluralized? Are objects singular? Are there single letter variables? Do function names relate what they return?
10. Check again if anything can be removed or simplified

These are some steps I think through during code review

[ender minyard]

Putting structures in place that don't let bugs go to production.

[Michael Levan]

Agreed! What structures would you add?

[ender minyard]

Unit testing! I'm trying to figure out unit testing for my own CI/CD pipeline this very moment.