One can distinguish between patterns that should be forced (e.g. brace placement) and patterns that should remain up to the programmer (e.g. whether a particular “if” statement may be single-line). Meaning, using a formatter can still allow the same code to be formatted in different ways. (Where to insert blank lines for visual structuring is maybe the most obvious example. You wouldn’t want to automate that.) It’s thus a spectrum rather than an all-out black and white.
> Where to insert blank lines for visual structuring is maybe the most obvious example. You wouldn’t want to automate that
In general, I agree, but I actually had some success doing that in a couple cases with custom linter rules.
Some tests were becoming unreadable because of lack of separation between sections, so I started enforcing. We also enforced at least two more spaces in between setup/execute/verify sections, where expectations could only show up in the third section.
This can be annoying if you use a different style, but all our tests followed the same patterns, so it made sense to enforce.
