[Vinnl]

I don't think I've ever seen style so divergent that it actually hampered my ability to change the code. Add a tool to automatically apply some stylistic choices if you want, but as soon as it becomes extra work to adhere to a specific code style, it quickly deteriorates to causing more work than it saves.

[thelean12]

Yeah we have tools where I work that deals with 90% of style errors, and reviewers call out the other 10%. After a few weeks it's all second nature so you don't have to do much to adhere to the guidelines and just do it while writing the code in the first place.

To me ignoring style is kind of like slipping a PR/diff/cl through without unit tests. Sure, that individual CL won't be the downfall of the codebase, but repeated offenses will destroy the codebase without an easy way to fix it all. Of course, without unit tests you end up with an unmaintainable fragile codebase, and without style you end up with an ugly, hard to read codebase.

[Vinnl]

It's exactly the same: if I think a style change is going to lead to "destroying the codebase" with repeated offences (rare - and should've been a transparent autofix if so) I'll call it out, and the same holds for a unit test. If you have a good reason to skip a unit test (e.g. isolated all stateless code, where the remaining code is almost trivially correct but hard to test) then that's fine (if it's noted as such), but otherwise I'll call it out.

It's just that skipping unit tests without good reason is far more likely to "destroy the codebase" (or at least to cause more work down the road than it saves now, without there being a good reason to skip that work now) than not adhering to some style guide will, IME.