Exceptional coding style

[deadalnix]

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.