> For me, it's whatever I need to do to get through code review without arguing too much. I agree with this. It takes a lot of context to truly understand anot

> For me, it's whatever I need to do to get through code review without arguing too much. I agree with this. It takes a lot of context to truly understand another's code so reviews are just smoke & style checks, not real logic scrutiny like a kernel dev might do - in most cases businesses aren't willing to accept the true cost of such a review; I think the same is true of KT. > Don't add linter checks for these things, it's condescending. disagree. wrt pep-8 stuff, devs should be using their own linters before code is properly committed and for review. CI checks are easy to add and manage a quick/easy rebuke for the dev that doesn't bother. For other style lints, tools that standardise trivial things (style w/ black, orderings w/ isort) reduce arguments and establish a consistent style. Code in whatever style you like, just standardise it for consumption. devs then argue at a higher level instead: over linter parameters.