On Saturday, 10 January 2015 at 22:11:55 UTC, Walter Bright wrote:
> On 1/10/2015 12:17 PM, Walter Bright wrote:
>> Has someone made a dfmt, like http://gofmt.com/ ?
>
> Next question - standalone tool, or built in to dmd (like Ddoc)?
>
> BTW, I think dfmt would be a significant win for D:
>
> 1. people expect this sort of thing these days
> 2. it tends to end bikeshedding arguments about the right way to format things
> 3. it'll help standardize the format of D code in the D repositories
> 4. it's simply nice and convenient!
> 5. it's a great first step when you're faced with fixing someone else's crap code
>
> I don't think it'll be hard to do as a builtin feature of dmd.
>
> My only concern about it is if dfmt is changed, then we get faced with a blizzard of changes in the D github repositories.

I agree that there should be a tool like this for D, don't care if it's stand-alone or part of dmd.

In my experience submitting PRs on github, 2. and 3. would definitely be alleviated by dfmt, as there's sometimes review comments about formatting and they'd go away if you just told all contributors to run dfmt first, to get the patches in a standard format.

As for your concern about github formatting commits, inevitable cost of standardizing and then changing your mind.

Can this problem be solve on Text Editor level?

I use Sublime, and I need some tool for code formating. Maybe there is any ready to use addons for D?

On Saturday, 10 January 2015 at 22:11:55 UTC, Walter Bright wrote:
> On 1/10/2015 12:17 PM, Walter Bright wrote:
>> Has someone made a dfmt, like http://gofmt.com/ ?
>
> Next question - standalone tool, or built in to dmd (like Ddoc)?
>
> BTW, I think dfmt would be a significant win for D:
>
> 1. people expect this sort of thing these days
> 2. it tends to end bikeshedding arguments about the right way to format things
> 3. it'll help standardize the format of D code in the D repositories
> 4. it's simply nice and convenient!
> 5. it's a great first step when you're faced with fixing someone else's crap code
>
> I don't think it'll be hard to do as a builtin feature of dmd.
>
> My only concern about it is if dfmt is changed, then we get faced with a blizzard of changes in the D github repositories.

Since Brian Schott already wrote a dfix, it seems easier to make dfmt the same program.

On Saturday, 10 January 2015 at 22:11:55 UTC, Walter Bright wrote:
> On 1/10/2015 12:17 PM, Walter Bright wrote:
>> Has someone made a dfmt, like http://gofmt.com/ ?
>
> Next question - standalone tool, or built in to dmd (like Ddoc)?
>
> BTW, I think dfmt would be a significant win for D:
>
> 1. people expect this sort of thing these days
> 2. it tends to end bikeshedding arguments about the right way to format things
> 3. it'll help standardize the format of D code in the D repositories
> 4. it's simply nice and convenient!
> 5. it's a great first step when you're faced with fixing someone else's crap code
>
> I don't think it'll be hard to do as a builtin feature of dmd.
>
> My only concern about it is if dfmt is changed, then we get faced with a blizzard of changes in the D github repositories.

I guess dfmt is to small for GSOC but could we bundle it with some other important tool to create a bigger task?

Best regards,
NVolcz

On 2015-01-10 23:11, Walter Bright wrote:

> Next question - standalone tool, or built in to dmd (like Ddoc)?

Ideally the dmd front end should be available as a library then dfmt should be a separate tool that uses the same front end library as dmd. But I know that we're not there yet.

It's always nice if a tool is built as a library with a with executable on top. This allows for other tools to be built using this library.

-- 
/Jacob Carlborg

On 1/11/2015 2:00 AM, NVolcz wrote:
> I guess dfmt is to small for GSOC

I'm not so sure. If the code has no comments, it's trivial. Handling comments, though, can be a bit of a challenge.

On Saturday, 10 January 2015 at 22:11:55 UTC, Walter Bright wrote:
> On 1/10/2015 12:17 PM, Walter Bright wrote:
>> Has someone made a dfmt, like http://gofmt.com/ ?
>
> Next question - standalone tool, or built in to dmd (like Ddoc)?

Please don't make the compiler-executable modify source code. It makes makefile editing more "dangerous".

A standalone tool is appropriate.

On Sat, 2015-01-10 at 14:11 -0800, Walter Bright via Digitalmars-d wrote:
> On 1/10/2015 12:17 PM, Walter Bright wrote:
> > Has someone made a dfmt, like http://gofmt.com/ ?
> 
> Next question - standalone tool, or built in to dmd (like Ddoc)?

Why in the compiler, source code formatting is not a compilation issue. Of course the issue is parsing to AST, which the compiler has, but doesn't provide as a library. In Go, the parsing code is separated from the compiler so that different tools can be constructed using different combinations of the same code.

Also why in DMD and not in LDC or GDC?

> BTW, I think dfmt would be a significant win for D:
> 
> 1. people expect this sort of thing these days

Thanks to Python PEP-8 and Go, yes. Personalized code formatting is increasingly a thing of the past, programming languages are now opinionated and fascist when it comes to formatting. Even if the rules are wrong.

> 2. it tends to end bikeshedding arguments about the right way to format things

Except when the tool implements the wrong style.

> 3. it'll help standardize the format of D code in the D repositories


Even if it is the wrong formatting standard?

I have to admit that the Phobos format rules make the code look appallingly ugly to me, sufficiently so that I really do not want to work on that codebase. I guess I am biased towards K&R C (which I use to drive my C++ style), Java and Go.

> 4. it's simply nice and convenient!

Working with Go in Emacs or LiteIDE is a bit of a joy as you get full reformatting on save. Fortunately I only have two main gripes with the Go formatting style, but no-one has a choice, use the Go style as dictated by the Go team at Google or do not use Go.

> 5. it's a great first step when you're faced with fixing someone else's crap code

Having just taken on a C/C++ codebase, I can agree that manually reformatting is a great way of "getting in" to the code. Then an automated formatting would contribute as well.

> I don't think it'll be hard to do as a builtin feature of dmd.

It should be a separate tool not a part of one of the three compilers.

> My only concern about it is if dfmt is changed, then we get faced
> with a
> blizzard of changes in the D github repositories.

Tough ;-)

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Sun, 2015-01-11 at 11:04 +0100, Jacob Carlborg via Digitalmars-d wrote:
> On 2015-01-10 23:11, Walter Bright wrote:
> 
> > Next question - standalone tool, or built in to dmd (like Ddoc)?
> 
> Ideally the dmd front end should be available as a library then dfmt should be a separate tool that uses the same front end library as dmd. But I know that we're not there yet.

And written in D :-)

> It's always nice if a tool is built as a library with a with executable on top. This allows for other tools to be built using this library.

dmd, ldc, gdc, dfmt, ddoc, lots of programs one parsing library required.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Saturday, 10 January 2015 at 22:11:55 UTC, Walter Bright wrote:
> On 1/10/2015 12:17 PM, Walter Bright wrote:
>> Has someone made a dfmt, like http://gofmt.com/ ?
>
> Next question - standalone tool, or built in to dmd (like Ddoc)?

I think best approach is akin to git subcommands - you can call stuff via `git command` but it in fact runs separate `git-command` binary behind the scene (which can also be used stand-alone). I would love to see DDOC implemented that way too.