Exceptional coding style

[Artur Skawina]

On 01/18/13 11:28, deadalnix wrote:
> 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.

(No (or small enough) gain) - (real (tangible) loss) < 0.

If you wonder where the loss comes from, others have mentioned some sources
in this thread already. I'm just pointing out the lack of gain and additional
loss components.

>> 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.

Consider several developers that each stick to there own style. The autoformatter
will take care of things when the upstream pulls their changes, right? Except,
then they each need to use their own private autoformatters in order to merge all
upstream changes, which includes re-merging their own work. Imagine what that does
to the revision history. Now consider how merging work from coder A by developer B
will work. Then merging the result back, B->A. Then pushing upstream. And merging
back by every developer.
It should be obvious that any sane use of an autoformatter would have to be at 
the local commit phase. But, then a *checking* tool which enforces a common style
would be the right solution; an autoformatter would just get in the way (you'd
have to effectively merge its changes back after every single commit).
Writing the code properly in the first place is a much better approach, the
checking tool can catch any mistakes. If there are enough of them and you almost
always need a mechanical tool to do the fixing, then you are doing something wrong. 

BTW, if an autoformatter helps you to perform merges, then the same logic can be
put in the merge tool - making that argument irrelevant.

artur