"Style" is such a small part about what people generally care about when they talk about code quality though, useful/intuitive abstractions, the general design and more tends to be a lot more important and core to the whole code quality debate.

Amateurs are the one who argue about syntax.

Code quality is about how well a piece of code expresses what it intends to do. It’s like quality writing.

> And there is the problem. Then you start arguing about brace positions and function names and whether simple data classes should have docstrings on properties or not.

In my 15 years of experience I have not worked at a place like this. Those are distractions. Anytime something about style has been brought up, the solution was to just enforce a linter/pre-commit process/blacklist for certain functions, etc. It can easily be automated. When those tools don't exist for particular ecosystems we made our own.

> And there is the problem. Then you start arguing about brace positions and function names and whether simple data classes should have docstrings on properties or not.

Holy strawman Batman!

Have you ever given a code review? These are the lowest items on the totem pole of things usually considered critical for a code review.

Here’s an example code review from this week from me to a colleague, paraphrased:

“We should consider using fewer log statements and raising more exceptions in functions like this. This condition shouldn’t happen very often, and a failure of this service is more desirable than it silently chugging along but filling STDOUT with error messages.”