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.win...@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder