4 ms·
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 row
by cbhl 7y ago
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.
- ridiculous_fish 7y ago> 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 Comments can be a low-key forced line break: int matrix[16] = { 0x0, 0x1, 0x2, 0x3, // 0x4, 0x5, 0x6, 0x7, // 0x8, 0x9, 0xA, 0xB, // 0xC, 0xD, 0xE, 0xF, // };
- saagarjha 7y agoUsually in cases like these I prefer to add the magic “formatter off” comment around the block: it’s self-documenting.