On Saturday, 14 March 2015 at 23:15:35 UTC, Brian Schott wrote:
> First, a disclaimer: I am an idiot for starting this thread.
>
> Moving on...
>
> I'm working on a list of configuration options for dfmt - a formatter for D source code.
>
> So far I have the following:
>
> * Insert spaces between if, while, for, foreach, etc loops and the "("
> * Allman vs One True Brace Style (Already supported by commant-line switch)
> * Operators at the end of the old line vs beginning of the new line when wrapping long expressions.
> * Insert space after the ")" of a cast expression
> * Make "case" and "default" match the indent level of the enclosing "switch"
> * Labels for loops always on their own line vs the same line as the loop
> * Labels outdented one level
> * Label indentation matches the most recent "switch"
> * Hard limit for line length
> * Soft limit for line length
>
> What am I missing?

First of all look at AStyle. It has plenty of options.

And There are some D specific options: templates constraints, function contract, static if (I would prefer do not ident code in static if block, for example).

Actually I with my student work also on code formatter, but we go deeper (may be too deeper :) ), unfortunately we haven't much time. And we wish you good luck with dfmt!!!

On Saturday, 14 March 2015 at 23:15:35 UTC, Brian Schott wrote:
> * Hard limit for line length
> * Soft limit for line length

offset for line wrap, e.g:

- right guide = 80;
- right tolerance = 10;

if line length = 84 then no new line
if line length = 91 then new line from the leftmost token before the 80th column.

I've recently used another formating tool which is too strict with the right guide because it's often not desirable to start a new line if the last token is just 5 chars over the guide.

On Saturday, March 14, 2015 16:48:21 Walter Bright via Digitalmars-d wrote:
> On 3/14/2015 4:15 PM, Brian Schott wrote:
> > What am I missing?
>
> I suggest defining "The One True Way" and have no configuration options.

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. Let's _please_ not try and force any particular style on the D community.

- Jonathan M Davis

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.

Walter, please understand, that no choice alone (in vacuum) is good or bad. "One true way" was good decision for Go because it comes as part of consistent opinionated approach to language design. It isn't just matter of formatting but applies to all decisions - either you do what language authors consider "right" or simply can't use the language properly.

There is certain appeal in such attitude but many people (including me) chose D for its pragmatical power and possibility to tweak the language use for specific project/company needs. You will only get more community fragmentation by going this way.

On 3/15/2015 2:38 AM, Dicebot wrote:
> Walter, please understand, that no choice alone (in vacuum) is good or bad. "One
> true way" was good decision for Go because it comes as part of consistent
> opinionated approach to language design. It isn't just matter of formatting but
> applies to all decisions - either you do what language authors consider "right"
> or simply can't use the language properly.
>
> There is certain appeal in such attitude but many people (including me) chose D
> for its pragmatical power and possibility to tweak the language use for specific
> project/company needs. You will only get more community fragmentation by going
> this way.

In general I agree with you, but I don't understand how a brace style serves specific project needs.

I used to get het up about how many spaces a tab has, but the older I get the sillier those arguments seem.

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.

D is a very flexible language, but there are things that were deliberately put in the language to remove some types of flexibility. These were based on my discussions with programming managers who were fed up with trying to reconcile code bases produced by different teams. One of those is the debug statement.

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.

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.

Before this gets even more out of hand[0] I'd like to point out that handling the two different brace styles and spaces-vs-tabs is about 20 of the nearly 2000 lines of code in dfmt.

These two options have been related to maybe 3 of the 100 issues filed against the tool. It's just really not a big deal compared to the line wrapping and indentation matching that needs to be done regardless of which color the bike shed is.

[0] Remember when I said I was an idiot for starting this thread?

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.

making the formatter customizable is a good thing, it will encourage people to work on phobos more because they can format it to their liking when working on it, then format it back to the `D-style` settings when committing. IIRC, Russel was just complaining about this a few days ago.

the default style should obviously be the D style.

On Saturday, 14 March 2015 at 23:49:00 UTC, Walter Bright wrote:
> On 3/14/2015 4:15 PM, Brian Schott wrote:
>> What am I missing?
>
> I suggest defining "The One True Way" and have no configuration options.

One of the big benefits of auto-formatting is that people don't have to agree on the correct style, because switching between them is trivial. Someone doesn't like phobos formatting? They can have it whatever way they want while they edit/debug it, then switch to official style for a pull request.