On Friday, 18 January 2013 at 07:58:57 UTC, Artur Skawina wrote:
On 01/18/13 07:45, Mehrdad wrote:
On Friday, 18 January 2013 at 05:41:00 UTC, Artur Skawina
wrote:
This is one of the reasons why automatic code formatting is
such a bad idea.
In what language? In C# it's actually a fantastic idea.
Every language. Not only does it mean that the heuristics
mentioned by Walter
can't be used (which isn't the main problem, as the error rate
is way too high),
but skipping of the manual
(re-)formatting-and-verifications-phase actively
reduces code quality by removing opportunities for extra
review, discovery of
refactoring possibilities and reflection.
Sane, but badly formatted code is much preferable to bad, but
pretty code. The
former can be easily fixed. Ugly code, that also happens to be
bad, will be
found and fixed as part of that process.
Auto formatting loses information which makes spotting the
truly bad code harder.
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.
