dfmt options

[Idan Arye via Digitalmars-d]

On Sunday, 15 March 2015 at 09:10:13 UTC, Walter Bright wrote:
> On 3/15/2015 1:12 AM, Jonathan M Davis via Digitalmars-d wrote:
>> Which would instantly make it useless for many users, because 
>> many of them
>> will disagree with the "One True Way" regardless of what it 
>> is. Tabs vs
>> spaces, BSD Allman bracing vs K&R bracing, if(...) vs if 
>> (...), ( test1 &&
>> test2 ) vs (test1 && test2), etc., etc.
>>
>> It's one thing to decide on a standard format that the 
>> official projects
>> would use. It's quite another to say that that's how all D 
>> programs in
>> existence should be, which is basically what we'd be doing if 
>> we made dfmt
>> only support one style. There's already quite a range in what 
>> folks do with
>> their D programs - be they personal or at companies which use 
>> D.
>
>
> A few years ago, I would have agreed with you. Today, I'm not 
> so sure:
>
>   https://golang.org/cmd/gofmt/
>
> Note the lack of configuration. Generally, it's been a big 
> success for Go.
>
> The advantages are:
>
> 1. People stop spending time bikeshedding over formatting. I've 
> read that gofmt users express relief over this.
>
> 2. After 40 years of programming, I certainly am tired of 
> formatting debates, and wish to spend my time on more 
> interesting things.
>
> 3. Straightforward incorporation of diverse code without having 
> to reformat them making git histories more difficult.
>
> > Let's _please_ not try and force any particular style on the
> D community.
>
> Forcing is a little strong. dfmt is an optional tool, not the 
> core language.

The thing is - gofmt was where from the very beginning of Go(or 
at least from r56, the first stable release. I didn't dig any 
deeper...). This means that any Go project was using the one true 
style from the beginning. dfmt, on the other hand, comes out when 
the D is 15 years old, and there are already projects using it, 
not necessary follow the Phobos style(or whatever one true style 
that was not yet agreed on...)

"This language has strong, well defined conventions for stuff 
you'd otherwise spend hours arguing on" is a good selling point 
for a language. "This language will somewhere along the way 
define conventions and force them upon you when you already have 
a large code base that might not fit these conventions" - not so 
much.

And yes, it's not really forcing because no one is forcing you to 
use dfmt. Or D. Or a computer. No - you are just forced to do so 
if you want to use dfmt. The thing is - when creating a tool, you 
need to make it usable. And a tools usability depends on people 
being able to use it. And if dfmt only supports the one true 
style, and my project happens to not be in the one true style, if 
only for the fact that the time that project was started was 
before the time of writing these lines, in which there is no 
declared, agreed-upon one true style - then in order to use dfmt 
I'll need to:

1) Convince the team to change the project's style. Knowing how 
non-controversial the subject of coding style is among 
programmers, this will surely be a quickly-resolvable debate.

2) Convince the project manager to allocate the time needed for 
the change. Seeing that there are never any pressing tasks in 
development teams, they'll probably easily agree.

3) Do the actual change. This part will probably go smooth - and 
I'm not sarcastic on this one - since we have dfmt. Of couse - 
this can only be done once dfmt is stable - I wouldn't dare 
entrusting the entire codebase to it at this stage, even though I 
won't mind working with it and fix code when it gets broken 
before my eyes(which will also allow me to open an Issue)

4) Apply the style changes to all the side branches. Well, 
merging style changes is known to be an easy, merge-conflict-less 
task...


Style overhaul for a big project is not rarely feasible...