dfmt options

Walter Bright via Digitalmars-d digitalmars-d at puremagic.com
Sun Mar 15 02:10:13 PDT 2015

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:


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.

More information about the Digitalmars-d mailing list