dfmt options

[Szymon Gatner via Digitalmars-d]

On Sunday, 15 March 2015 at 10:12:09 UTC, Dicebot wrote:
> On Sunday, 15 March 2015 at 10:03:15 UTC, Walter Bright wrote:
>> Haven't we all got better things to do than argue about 
>> formatting styles? If I was a manager paying programmers $$$$, 
>> I do not want to pay them to argue about formatting, either.
>
> But this is exactly the point! There is a team with already 
> established coding style. Suddenly switching those because of 
> upstream will create inevitable tension and decrease in 
> efficiency until people adapt to new style and form new habits. 
> And this will be investment with exactly 0 resulting benefit. 
> Most likely pragmatical decision would be "stick to existing 
> style and ignore dfmt existence". Or "fork that tool and add 
> our style" if that is small effort.
>
> It is also matter of expectation. Until now D was very 
> un-opinionated language, probably even closer to language 
> construction set. If this changes for one case, one may fear 
> more similar decisions may follow.

I am very much with Walter on this.
1. There are not many big teams with huge D projects out there 
yet.
2. Team doesn't have to format their code with dfmt if they don't 
like its style then they don't have to adapt to anything
3. In my experience there are many programmers that don't care 
about any style and actually following a team style is tedious 
for them, they would rather use automatic formatting tool (with a 
hotkey) to do their job for them and call it a day
4. Consistency is MUCH more important than personal opinions, not 
just within a team but in whole language ecosystem, as it makes 
much easier to follow 3rd party libraries for the team members 
too.

and to add oil to the fire ;) Some style opinions are objectively 
more right then others (for visual reasoning) [1]

[1] https://vimeo.com/101084305