On Friday, 18 January 2013 at 08:13:48 UTC, deadalnix wrote:
Believing that one code formatting will inherently be better
than what a formatted can do is very similar to the assertion
often heard that code generated by the compiler is worse than
hand written assembly or many other recurring similar topic
coming again and again in dev discussion.
It has been shown more than once that you can beat the compiler
on some carefully selected piece of code, but generally
speaking, you have not even a small chance to beat it at a
program scale or when certain optimizations kicks in. Same goes
for the formatter.
As a matter of fact, the time you spend formatting can be
better spent elsewhere, and the consistency you win in the
process has many benefits : cleaner diffs and easiers merges
because you have no formatting conflict. The codebase is
consistent, and the tool can even help you by reformatting
confusing stuff is clearer ones.
Not to mention that all refactoring tools suffer badly if you
don't have a proper formatter : you spent as much time
reformatting the code than you would have needed to do the
refactoring itself.
When reading your post, I thought of replacing the concept of an
automatic source code formatter with an automatic garbage
collector. We've seen this kind of debate before, with the same
sort of arguments in favor and against.
It could very well be that so long as the implementation is good,
the idea of a standardized enforced format may be better than the
current alternative. It's like the difference between machine
tooling vs what you get from an anvil and hammer approach.
Consistency vs inconsistency.
--rt