Every time when discussion of code quality comes up, for example at code review, you encounter the fact that for everyone this is a very relative concept. As many people as many opinions. Even if you take some objective metrics, combining these metrics under the banner of "quality code" still won't be objective, everything depends on the starting point. Projects are different, at different stages of their development, they have their own priorities and as usual the answer to all questions is "it depends".
But I became curious to abstract and formalize in my head what quality code is. How to distinguish quality from non-quality?
Absolute
In my opinion, the standard of code quality is its absence. If there's no code, then you don't need to worry about it, it doesn't become outdated, you don't need to maintain it, human, economic and technical resources aren't spent on it - beauty. And here I don't mean fashionable zero-code solutions, if very roughly simplified, by code I mean literally any products of people's life activity - code, documentation, poked checkboxes in a visual interface, anything that should do some work. So we come to the fact that the main problem of the absence of code is it doesn't do any work. And sometimes it's needed.
Simplicity
When we need it we write it. And the main criterion of quality in my opinion is simplicity, which, however, beautifully interweaves with the previous thought: absence of code is simplicity taken to the absolute. What is simple code? But this is already a more difficult question. An excellent indicator of simplicity is how easily it's understood by not very experienced or just recently immersed in the project developers. How many questions a person has to ask themselves before they understand it and especially change it. The fewer questions - the better. Contrary to obvious logic, a senior isn't the one who writes complex code, a senior is the one who writes the simplest code in the current situation. That is, simple for simple, complex for complex.
Time
So it happened that on all projects where I worked, code quality improved many times simply by adding static analysis with default settings. After all, until that moment, code quality wasn't checked at all. Because of this, I have some bias slightly towards code, not towards business, although it's perfectly clear that there should be some trade-off here. Business in the moment very weakly cares how you have spaces arranged in your code, it's important to them that it was written "yesterday". This naturally also can't be forgotten. Good code is that which is written as quickly as possible for continuing business functioning. Remember at least one startup that took off that wasn't terrible at first. This is all because quality is ignored to some degree of life importance there, and when things are going uphill and resources appear, then you can already allocate resources for this. Through pain and suffering of workers, of course, but no Instagram or Twitter would have simply appeared if they aimed for a multi-million audience right away without cutting any corners. You need to understand what tasks the business is solving right now and what plans it has. After all, what's the point of bothering and making incredibly expandable architecture, spending a bunch of time on this, if the project won't be needed by anyone at all in a month? This point also interweaves nicely with the first thought: absence of code is code written as quickly as possible, faster is simply impossible.
Where's the line?
There's no line between quality and non-quality code really, it's a gradient. Lines can only be set at the level of a specific person, and for everyone they'll be different. Everything depends on previous experience and breadth. For me the main guiding metric is if I understand that on a constant basis I'm doing tasks much slower than I could (than on another project, for example), asking myself too many questions or existing code forces me to generate even more tech debt. And this of course doesn't mean that such code is immediately BAD in absolute terms. This means that for me to work with it given my experience is uncomfortable, I'll make every effort to improve it to the level of normality in my head. If there's no movement towards this for months and years, this is a direct path to loss of motivation and burnout. At the same time, I want to note, a person with less experience might have a completely positive attitude due to the fact that they haven't seen how it can be yet. Truly the less you know the better you sleep. On the other hand, often the time and effort to write "bad" and "good" code doesn't differ so much, the first is written because they don't know how to write the second. This is exactly where experience wins.
What tech debt is acceptable and what isn't? If some legacy feature lies somewhere in a corner of the project and almost doesn't draw attention to itself, that's okay. If every developer on the project loses time on this every day - that's a serious reason to think. Especially if there are many developers. And this is of course also a gradient.
Long term
In previous paragraphs I mentioned what worries business in the moment, but business should also understand the long-term consequences of closed eyes to tech debt. People can get upset, quarrel, quit, as often happens taking with them life-important expertise, because earlier they didn't take care to diversify it among different people or documentation, all this can fall apart by domino effect, where one employee quitting entails a chain of others. And just losing a person in the current candidate market is fraught with huge financial losses, because if you're not Google, then you most likely don't have queues of top candidates at your door.
Practice
Number of static analysis warnings, number of returns and new created bugs by testers, number of crashes for users - all this to some degree are indicators of code quality. Even the psychological state of each person on the project directly depends on it. Usually the bigger the project and the more workers on it, the more frameworks and bureaucracy. This is not by chance, frameworks help all participants adhere to some common paradigm. Code review - now a basic thing, if you have at least two people working, the time has come. I think you should only look at potential bugs, possibility of replacing a new bicycle with some existing component, code readability in terms of naming and unforced complexity. Static analysis - another such framework, start with the default configuration, prohibit writing new warnings. This way you'll free developers from disputes at code review and in personal messages. Any disputes should end with documentation or automation with custom lint rules or tests, so that such a situation doesn't arise again. Make a CI pipeline that will run all automation, for example on pull requests, merge or on schedule. And in general - start counting metrics, any numbers on which you think the project quality depends. It's almost impossible to keep everything in your head, and feelings can be deceptive. From the architecture point of view, the main principle is that explicit is always better than implicit, write code so that you can throw out a small piece and replace it with another, don't overcomplicate without reason. In a bad project, shitty code is smeared in an even layer across the entire project, in a good one - concentrated in small separate piles.
Conclusions
- There's no objective metric, quality criteria are different for everyone
- Every project and team is different, always need to start from the specific situation
- Sometimes you need fast
- Sometimes you need simple
- Understanding how it can be in general is the main thing in experience
- Need to adhere to an ideal picture of the world, but adjust to the environment
- Sometimes it's faster to write qualitatively than not
- Catch yourself on your feelings and unwind them in favor of improving the project
- If it seems to you that you're doing the same thing - automate
- If it seems to you that something is difficult - simplify, it's not only difficult for you