This doesn't seem correct to me. Each of these categories should bear equal weight, I won't spend less time on code style or tests to spend more time on API design. My code review checklist is a checklist. I spend as much time as necessary on each item in the checklist, no more no less.
I also think that code style, fuzzing, and benchmark tests are the most important items on my checklist. It keeps the code base from becoming a jenga tower that is brittle to change. It also keeps us honest as to whether a feature is a perf hit or not. Tests are far more important than this graphic portrays them as.
Code style is the first thing I eliminate from a review process. I find the most commonly used code formatter and linter for $LANG (the more opinionated the better) and plug it into pre-commits and CI. Code style is just not worth my time.
But, code formatting is not a solved problem, right ?
You either have to fiddle until the formater outputs proper layout, or let it rest as is and never learn how to format your code, letting the code base leaking tons of probable less than ideal layout.
The proper layout is whatever the formatter outputs. That's the point. Everyone uses the formatter and accepts whatever it does, and nobody needs to think about it anymore.
I'll take a consistent less than ideal layout over whatever $HUMAN comes up with. But to me an inconsistent layout is the less than ideal one. And humans excel at inconsistency.
You're conflating style with formatting. No formatter will tell you if you've picked clear names or need to decompose or combine something for better readability.
As long as the starting point is what an opinionated formatter spits out, then we can talk about the hardest thing in software engineering (naming things). But lets be real, most "code style" conversations are of the formatting variety and they're the purest form of bike shedding.
I also think that code style, fuzzing, and benchmark tests are the most important items on my checklist. It keeps the code base from becoming a jenga tower that is brittle to change. It also keeps us honest as to whether a feature is a perf hit or not. Tests are far more important than this graphic portrays them as.