On Sun, 15 Mar 2015 14:49:35 +0100, Mathias Lang via Digitalmars-d wrote:

> but One True Way would just lead to fork

exactly!

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

On 03/15/2015 12:48 AM, 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.

It's a bit late to enforce a particular D code style on all the existing
code and people already using D.
Something like clang-format's style configurations seems more appropriate.
http://clang.llvm.org/docs/ClangFormat.html

And of course that would include an endorsed phobos/dlang default style.

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?

Are you planning on making all these options command-line flags? When you invoke dfmt via an editor plugin it doesn't matter much - but if there are a lots of options, having each editor support all of them will require all the plugin maintainers to always keep their plugins up to date. Otherwise, a team that wants to use dfmt will be limited to the lowest common subset of formatting options supported by the editors of all team members.

How about making dfmt read it's configuration from a file? That way, a project can a dfmt.json file or something in it's root directory, and all editors will point it to this file.

If you choose to use this approach, dfmt should also be able to emit a template of this file(fully configured to the one true style, whatever that may be), and you should consider if you want to allow a default dfmt style file in the user's home directory or if you want to force users that work on unconfigured projects to always use the default(though it should be easy enough for an editor plugin to allow the user to have a default style file).

On 3/15/2015 3:12 AM, Dicebot wrote:
> 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.

That's not entirely correct. For example, the rules for operator overloading are set up to discourage things like C++ iostreams.

Nevertheless, nobody is going to force dfmt on anyone. It will remain a separate tool, not welded into the language.

However, I do anticipate that official D source code, like for Phobos, will require dfmt.

On 3/15/2015 10:37 AM, Idan Arye wrote:
> 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...)

There is indeed the Phobos style, but it isn't 100% adhered to because one needs a tool like dfmt to make that work.

On 3/14/2015 8:32 PM, Rikki Cattermole wrote:
> This might be a bit of a out of scope, but auto generating of DDOC comments for
> symbols would be nice. Basically to enforce before e.g. committing that
> everything has been explained.

Autogeneration of documentation is by definition useless. Documentation is for 'why' and 'how'. Autogeneration can never be more than reformatted source code.

On Sunday, March 15, 2015 02:10:13 Walter Bright via Digitalmars-d wrote:
>  > 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.

Yes, sorry. Forcing is too strong a word. However, if we're putting out an official formatting tool which has no configurability, unless we're telling folks that it's specifically for the official source code, and that's it, we're basically recommending that the whole D community should format their code in that specific way, which I don't think is at a good idea. It may not be forcing, but it's still trying to promote a specific formatting style in a language that doesn't restrict its formatting.

And what does it cost us to make dfmt properly configurable like most formatting tools are? If someone wants to format their code in the same manner as ddmd and phobos and whatnot, then we'd still be making it easy for them, but we'd then also allow others to format their code they way that they wanted with a tool that understands D. If dfmt is not particularly configurable, I fully expect that the code will either be forked so that the rest of the D community can actually have a proper formatting tool, or a competing tool will arise at some point, but I would be very surprised if dfmt achieved widespread use within the D community if it weren't configurable.

And while the Go folks may have had success with pushing a specific format on everyone, I really think that Go attracts a different type of person than D does. Go is painfully simplistic, and while that attracts certain programmers, there are others of us who would hate using it. So, while I think that Go provides an interesting case for study, I don't think that doing what they're doing necessarily makes sense for the D community.

- Jonathan M Davis

On Sunday, March 15, 2015 03:02:53 Walter Bright via Digitalmars-d wrote:
> Haven't we all got better things to do than argue about formatting styles?

Sure, like we have better things than to argue about vim vs emacs. But I wouldn't want to be forced to use emacs (or micro-emacs) just because that's what you like to do. The same goes with formatting code in a specific way. It's not something that I want to argue over, but it's not something that I want pushed upon me either.

Sometimes, you just have to suck it up and format code the way that someone else wants, because it's not your project, and the formatting guidelines for the project aren't lax enough to let you code how you'd like to, but I hate it when I have to format code in ways that I don't like. It's like walking around with a pebble in your shoe. It may not stop you from getting any work done, but it's a constant point of pain.

Certainly, if dfmt isn't configurable, then for any D project that I have the opportunity to work on, I'd be fighting against using it, because there's no way that it would be formatting the code the way that I'd like. I expect that that battle is a lost cause with regards to Phobos and the other official source, but I'd actively discourage its use in any code that I'm involved with aside from that so that I could avoid having to deal with the formatting rules that it would be enforcing.

Having a configurable formatting tool doesn't fix that problem, because an unpleasant coding style can obviously still be required even without a formatting tool, but at least if it's configurable, it becomes possible to tweak a coding style and get closer to a desirable formatting style while still using the official formatting tool instead of being forced to use the same, unwanted style everywhere just because folks want to use dfmt.

- Jonathan M Davis

On Sun, 15 Mar 2015 13:23:09 -0700, Jonathan M Davis via Digitalmars-d wrote:

> Yes, sorry. Forcing is too strong a word. However, if we're putting out an official formatting tool which has no configurability, unless we're telling folks that it's specifically for the official source code

and then it will be forken in the blink of an eye, and turned into configurable, with "phobos" preset. and then nobody will use bundled dfmt, 'cause there will be no reason to, as forked one will be able to do anything bundled can and more.