Exceptional coding style

deadalnix deadalnix at gmail.com
Sun Jan 20 19:12:00 PST 2013


On Saturday, 19 January 2013 at 13:19:36 UTC, Artur Skawina wrote:
> (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.
>

Nobody demonstrated anything remotely close to that. You 
demonstrated a decorrelation, which is only sufficient to remove 
parameter from the equation (here code quality).

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

Why do a checking tool would be the right solution ? Why do 
manually the work that a machine can do automatically ?

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

No editor have to show you the code as it is actually foramatted 
in the source file. Actually, many don't, like IntelliJ. A 
formatter can work both directions.

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

Which would completely dumb. The only component in the toolchain 
that care about formatting is the programmer. It make perfect 
sense to put the formatter between the programmer and everything 
else in the toolchain.


More information about the Digitalmars-d mailing list