The title of the article is a bit of a misnomer. I don’t see best practices, but rather some high-level guidelines. It does have a useful collection of references, though.
If I can provide a counterpoint-in-part to the article, the citation of “Humanizing Code Reviews” is a red flag for me. I feel that code reviews and house style should be inflexible and impartial, and if they hurt the developer’s feelings, then the developer is too attached to the code and not thinking about its future. At my company, I use FindBugs and Checkstyle, which are rule-based static analysis systems, and are baked into the build and continuous integration process of all our projects. I’m all about de-humanizing code reviews.
Personally, if I find people on my team bickering about indentation or newlines or a where vs let binding, I will resolve the dispute by posting a picture of bicycles in a shed.
I strongly believe that not all code can be automatically formatted, and strictly enforcing “style” rules or the use of automatic formatting seems petty and bureaucratic.
I prefer the late Pieter Hintjens’ approach of just merging everything.