I'm not sure what exactly Linus means by this, but I read this as: for good programmers, coding is about managing data structures and their relationships whereas bad programmers are more concerned with just getting the thing to work.
there are two kinds of programmer: one thinks code is an artifact and that you can produce quality code. the other thinks code is excrement and only exists as a waste product necessitated by the immaturity of our information modeling tools.
I think it's more that bad programmers focus on surface details like code style. All too often I've seen a code review of a complex feature get derailed by nitpicking of inconsequential things like variable names, formatting, etc.
I rarely comment on code style for this reason. I want the review to focus on functionality, not style. I don't really believe the notion "imperfect code style is a code smell" anyway.
I have a contrary view on code style. If there's no semblance of consistency to the code you write, how can you possibly formulate a consistent and sensible architecture?
The style itself is inconsequential, but no consistent style is a red flag to me.
> how can you possibly formulate a consistent and sensible architecture?
Similar arguments could be made about actual architecture: "If you can't have well-designed and consistent houses, how can you possibly have a well-designed city?"
The best architectures I've seen, by far, had the worst code. Code is not a systemic level issue. The way the pieces fit together is.
A sad fact of good architectures is they actually enable bad code to exist without severe consequences, because that badness is localized.
Yes. For example, a distributed system composed of various microservices, where the microservices can use different code styles, different programming languages, be maintained by different teams, etc.
Variable names are the nouns of programming though. It’s not really related but I think having an “editor” try to read your text and give you improvement ideas is not “shallow”. The code is there for programmers to read and reason about so optimizing for “easy to load into your brain” code is important too.
let c = ... versus let customer_address = ... can save a lot of sanity throughout the years
I check both when doing reviews. Style and "cleanliness" of the code is important as other people are also expected to work with it. Also I follow the saying that code is more often read than (re)written, so that should not be neglected.
Structure of the code, as in relationship of classes, data flow and high level design is also important and checked during review.
Variable names are the only thing that can reasonably guide you in time of need. Thinking that variable names are not all that important is not a good take.
