On Friday, 18 January 2013 at 09:10:38 UTC, Artur Skawina wrote:
On 01/18/13 09:48, Walter Bright wrote:
On 1/17/2013 11:58 PM, Artur Skawina wrote:
Sane, but badly formatted code is much preferable to bad, but
pretty code.
Offhand, I can't remember ever running across bad but pretty
code.
Which is my point. An autoformatter makes the bad code look
good, but does
not change its quality. Hence use of such a tool as part of the
std dev
process should be strongly discouraged, not encouraged.
Having it can be useful when refactoring, yes.
That is completely erratic reasoning. What you state here is that
the 2 issue are orthogonal, and that code quality is an
irrelevant topic when it come to pro/cons of a formatter. You
didn't demonstrate in any way that it is to be avoided.
If /formatting/ conflicts appear during merges, then it's a
sign of either
a) bad code, or b) bad process. Papering over either problem
with an
autoformatter is not the right fix.
Using an autoformatter is a sure way to fix the process if such
merging error occurs. The other way is to ask everybody to spend
their time formatting in a given way. Anyone that have managed a
project KNOWS that asking everybody to do something is not gonna
make it, either because people don't care or because people make
mistakes.
