There are always corner cases. For example, clang-format at $day_job doesn't understand semantically that I want my 4x4 matrix constant to be formatted as 4 rows with 4 numbers each; putting all 16 numbers in a single long array will get a lower score.
But as a whole, I found it easier to navigate the monolithic code base when most of it has been auto-formatted, exceptions aside. When applying a formatter to existing code, I usually do that in a separate commit and then follow it with any hand-rewritten lines afterwards (in case either the formatter or my changes afterwards accidentally regress something).
And once the formatter is enabled by default, it's usually easy enough to come up with a set of smaller statements that auto-format well to replace a longer statement that auto-formats poorly.
> For example, clang-format at $day_job doesn't understand semantically that I want my 4x4 matrix constant to be formatted as 4 rows with 4 numbers each
But as a whole, I found it easier to navigate the monolithic code base when most of it has been auto-formatted, exceptions aside. When applying a formatter to existing code, I usually do that in a separate commit and then follow it with any hand-rewritten lines afterwards (in case either the formatter or my changes afterwards accidentally regress something).
And once the formatter is enabled by default, it's usually easy enough to come up with a set of smaller statements that auto-format well to replace a longer statement that auto-formats poorly.