www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - dfmt options

reply "Brian Schott" <briancschott gmail.com> writes:
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?
Mar 14 2015
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Sat, 14 Mar 2015 23:15:34 +0000, Brian Schott wrote:

 First, a disclaimer: I am an idiot for starting this thread.
=20
 Moving on...
=20
 I'm working on a list of configuration options for dfmt - a formatter
 for D source code.
=20
 So far I have the following:
=20
 * 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
=20
 What am I missing?
optional space before arguments in function declaration, if you please.=20 i.e.: void foo(); vs void foo (); =
Mar 14 2015
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Mar 14 2015
next sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
On Saturday, 14 March 2015 at 23:49:00 UTC, Walter Bright wrote:
 I suggest defining "The One True Way" and have no configuration 
 options.
I hope you like tabs as much as I do.
Mar 14 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/14/2015 4:59 PM, Brian Schott wrote:
 On Saturday, 14 March 2015 at 23:49:00 UTC, Walter Bright wrote:
 I suggest defining "The One True Way" and have no configuration options.
I hope you like tabs as much as I do.
We'll all have to compromise at some point to have a One True Way, but it'll be worth it. I gave up on my cherished notion of tabs for the Greater Good in Phobos formatting, for example.
Mar 14 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/14/15 6:45 PM, Walter Bright wrote:
 On 3/14/2015 4:59 PM, Brian Schott wrote:
 On Saturday, 14 March 2015 at 23:49:00 UTC, Walter Bright wrote:
 I suggest defining "The One True Way" and have no configuration options.
I hope you like tabs as much as I do.
We'll all have to compromise at some point to have a One True Way, but it'll be worth it. I gave up on my cherished notion of tabs for the Greater Good in Phobos formatting, for example.
I think a simple starting point would be to define and enforce automatically one style for all phobos pull requests. -- Andrei
Mar 14 2015
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Andrei Alexandrescu"  wrote in message 
news:me2orn$2fjp$1 digitalmars.com...

 I think a simple starting point would be to define and enforce 
 automatically one style for all phobos pull requests. -- Andrei
And with ddmd, we can do the same.
Mar 14 2015
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Sunday, 15 March 2015 at 01:45:56 UTC, Walter Bright wrote:
 On 3/14/2015 4:59 PM, Brian Schott wrote:
 On Saturday, 14 March 2015 at 23:49:00 UTC, Walter Bright 
 wrote:
 I suggest defining "The One True Way" and have no 
 configuration options.
I hope you like tabs as much as I do.
We'll all have to compromise at some point to have a One True Way, but it'll be worth it. I gave up on my cherished notion of tabs for the Greater Good in Phobos formatting, for example.
Not even worth discussing. The very first thing I will do with "one true way formatter" is to fork it to define my own style.
Mar 14 2015
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 15.03.2015 um 06:55 schrieb Dicebot:
 On Sunday, 15 March 2015 at 01:45:56 UTC, Walter Bright wrote:
 On 3/14/2015 4:59 PM, Brian Schott wrote:
 On Saturday, 14 March 2015 at 23:49:00 UTC, Walter Bright wrote:
 I suggest defining "The One True Way" and have no configuration
 options.
I hope you like tabs as much as I do.
We'll all have to compromise at some point to have a One True Way, but it'll be worth it. I gave up on my cherished notion of tabs for the Greater Good in Phobos formatting, for example.
Not even worth discussing. The very first thing I will do with "one true way formatter" is to fork it to define my own style.
+1
Mar 15 2015
prev sibling next sibling parent reply "Orvid King" <blah38621 gmail.com> writes:
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.
At which point you realize that "The One True Way" is wrong, ask for it to be changed, and are then told that it is "The One True Way". Take tabs vs. spaces for instance, phobos' style guide states that indents should be 4 spaces, but I'd much prefer it to be a single tab. Correct me if I'm wrong, but I believe the purpose of a formatter is to make the formatting of the code consistent in the way that the user wants it to be.
Mar 14 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/14/2015 5:01 PM, Orvid King wrote:
 At which point you realize that "The One True Way" is wrong,
Maybe it's time to transcend that.
 Correct me if I'm wrong, but I believe the purpose of a formatter is to make
the
 formatting of the code consistent in the way that the user wants it to be.
https://golang.org/cmd/gofmt/ Note the lack of configuration. Generally, it's been a big success for Go.
Mar 14 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sat, 14 Mar 2015 18:44:02 -0700, Walter Bright wrote:

 On 3/14/2015 5:01 PM, Orvid King wrote:
 At which point you realize that "The One True Way" is wrong,
=20 Maybe it's time to transcend that. =20 =20
 Correct me if I'm wrong, but I believe the purpose of a formatter is to
 make the formatting of the code consistent in the way that the user
 wants it to be.
=20 https://golang.org/cmd/gofmt/ =20 Note the lack of configuration. Generally, it's been a big success for Go.
maybe it's time to fix the compiler, so it will simply reject the UnTrue=20 Sources? why relay to external tool for such fundamental task?=
Mar 15 2015
parent reply Mathias Lang via Digitalmars-d <digitalmars-d puremagic.com> writes:
2015-03-15 13:56 GMT+01:00 ketmar via Digitalmars-d <
digitalmars-d puremagic.com>:

 maybe it's time to fix the compiler, so it will simply reject the UnTrue
 Sources? why relay to external tool for such fundamental task?
That would be terrible. They are thing the compiler should enforce (IMO the `module name;` should be mandatory, and it should also warn if no documentation for the module was given when symbols inside the module are), but One True Way would just lead to fork, countless bikeshedding, and "I don't use D because I'm not free to format my code the way I want" arguments. Arguing on something as subjective as formatting is a loss of time, because you can find as many pros and cons as you want.
Mar 15 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
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!=
Mar 15 2015
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Mar 15 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Mar 15 2015
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
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.
Mar 15 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Mar 15 2015
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
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.
Mar 15 2015
next sibling parent "Brian Schott" <briancschott gmail.com> writes:
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?
Mar 15 2015
prev sibling next sibling parent "Szymon Gatner" <noemail gmail.com> writes:
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.
I am very much with Walter on this. 1. There are not many big teams with huge D projects out there yet. 2. Team doesn't have to format their code with dfmt if they don't like its style then they don't have to adapt to anything 3. In my experience there are many programmers that don't care about any style and actually following a team style is tedious for them, they would rather use automatic formatting tool (with a hotkey) to do their job for them and call it a day 4. Consistency is MUCH more important than personal opinions, not just within a team but in whole language ecosystem, as it makes much easier to follow 3rd party libraries for the team members too. and to add oil to the fire ;) Some style opinions are objectively more right then others (for visual reasoning) [1] [1] https://vimeo.com/101084305
Mar 15 2015
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Mar 15 2015
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Mar 15 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/15/2015 1:34 PM, Jonathan M Davis via Digitalmars-d wrote:
 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.
I fully understand your point of view on this, and used to share it. But as an older programmer, these sorts of issues just don't seem important anymore. Just adapt and move on to more interesting things. Spend the effort on something that counts. For example, I simply do not care what the One True Brace Style is anymore. I can't even understand why I used to care about it and argue about it. I'll use whatever brace style is in the code I'm working on, and it doesn't bother me in the slightest.
Mar 15 2015
prev sibling next sibling parent "weaselcat" <weaselcat gmail.com> writes:
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.
Mar 15 2015
prev sibling next sibling parent reply "Idan Arye" <GenericNPC gmail.com> writes:
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...
Mar 15 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Mar 15 2015
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Mar 15 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
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=20 configurable, with "phobos" preset. and then nobody will use bundled dfmt,=20 'cause there will be no reason to, as forked one will be able to do=20 anything bundled can and more.=
Mar 15 2015
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
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.
Mar 15 2015
prev sibling next sibling parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
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.
Mar 15 2015
prev sibling parent "Dragos Carp" <dragoscarp gmail.com> writes:
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.
+1
Mar 17 2015
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/14/2015 4:15 PM, Brian Schott wrote:
 What am I missing?
I'd also suggest making dfmt an algorithm. Then people can use it like map, reduce, filter, etc., in their programs. dfmt as a program then becomes incidental and trivial.
Mar 14 2015
parent reply "Brian Schott" <briancschott gmail.com> writes:
On Saturday, 14 March 2015 at 23:51:51 UTC, Walter Bright wrote:
 On 3/14/2015 4:15 PM, Brian Schott wrote:
 What am I missing?
I'd also suggest making dfmt an algorithm. Then people can use it like map, reduce, filter, etc., in their programs. dfmt as a program then becomes incidental and trivial.
I'm not sure if you're trolling or not. I mean, when you said that writing a D lexer and parser was a weekend project I knew that you were, but with this I'm not sure.
Mar 14 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/14/2015 4:58 PM, Brian Schott wrote:
 On Saturday, 14 March 2015 at 23:51:51 UTC, Walter Bright wrote:
 On 3/14/2015 4:15 PM, Brian Schott wrote:
 What am I missing?
I'd also suggest making dfmt an algorithm. Then people can use it like map, reduce, filter, etc., in their programs. dfmt as a program then becomes incidental and trivial.
I'm not sure if you're trolling or not. I mean, when you said that writing a D lexer and parser was a weekend project I knew that you were, but with this I'm not sure.
void format(OutputRange)(string source_desc, ubyte[] buffer, OutputRange output, FormatterConfig* formatterConfig) isn't quite set up as an algorithm. An algorithm would look like: auto format(InputRange)(InputRange r, string source_desc, FormatterConfig* formatterConfig) and would return another input range.
Mar 14 2015
prev sibling next sibling parent Mathias Lang via Digitalmars-d <digitalmars-d puremagic.com> writes:
2015-03-15 0:15 GMT+01:00 Brian Schott via Digitalmars-d <
digitalmars-d puremagic.com>:
 What am I missing?
I suggest you fire a recent version of Visual Studio and go to tools / Options / Tet editor / C# (or C/C++) / Formatting. There you got a bunch of formatting options. Maybe not all of them are relevant, but that can give some good ideas. There can be an (almost) endless stream of possibility for formatting, especially if you throw in the comments (e.g. put the comment for enums at the EOL, or always comment using '/**'...). Personal request: enforce that every block has a set of parenthesis.
Mar 14 2015
prev sibling next sibling parent "weaselcat" <weaselcat gmail.com> writes:
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?
Have you given clang's formatter options a read over? It might spark an idea or two. http://clang.llvm.org/docs/ClangFormatStyleOptions.html
Mar 14 2015
prev sibling next sibling parent reply "Meta" <jared771 gmail.com> writes:
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?
Maybe nobody else does this, but I prefer to write switch cases in an indented block style. switch (expr) { case 0: //Do stuff end; case 1 .. case 9: //Do other stuff end; default: //Do default stuff } In the same way, I indent attribute labels in classes/structs. I'm positive almost nobody else does that, however, so it's probably not an option you want to enable. class Test { private: //Methods, members public: //etc. }
Mar 14 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Sunday, 15 March 2015 at 00:51:30 UTC, Meta wrote:
 Maybe nobody else does this, but I prefer to write switch cases 
 in an indented block style.

 switch (expr)
 {
     case 0:
         //Do stuff
     end;

     case 1 .. case 9:
         //Do other stuff
     end;

     default:
         //Do default stuff
 }




 In the same way, I indent attribute labels in classes/structs. 
 I'm positive almost nobody else does that, however, so it's 
 probably not an option you want to enable.

 class Test
 {
     private:
         //Methods, members

     public:
         //etc.
 }
I do the same. On actual topic : having look at Eclipse C++ codestyle options may give many useful hints.
Mar 14 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-03-15 06:54, Dicebot wrote:

 On actual topic : having look at Eclipse C++ codestyle options may give
 many useful hints.
And for Eclipse Java formatting options. -- /Jacob Carlborg
Mar 17 2015
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/14/15 4:15 PM, 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?
* Deduce bracing style from code * Deduce indent size and spaces vs. tabs from code * Deduce max line length from code (typical boundaries: 72, 80, 100, 120). Andrei
Mar 14 2015
prev sibling next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Brian Schott"  wrote in message 
news:iobidfcyoneyxrzkhlik forum.dlang.org...

 First, a disclaimer: I am an idiot for starting this thread.
Hahaha.
 What am I missing?
- Enum members each on new line or all on same line - Threshold for array initializers, when exceeded each element is on own line eg auto x = [ item, item, item ];
Mar 14 2015
prev sibling next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 15/03/2015 12:15 p.m., 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?
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. Perhaps also change existing ones to match e.g. params and return variable.
Mar 14 2015
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sun, 15 Mar 2015 16:32:25 +1300, 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.
this never helps. what sense of having "documentation" like "enum=20 SomeType" for `enum SomeType`?=
Mar 15 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 16/03/2015 2:16 a.m., ketmar wrote:
 On Sun, 15 Mar 2015 16:32:25 +1300, 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.
this never helps. what sense of having "documentation" like "enum SomeType" for `enum SomeType`?
Ok enums probably wouldn't be. I'm more thinking of struct/classes/unions functions/methods properties and global variables. Maybe even head of module.
Mar 15 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 16 Mar 2015 02:19:08 +1300, Rikki Cattermole wrote:

 On 16/03/2015 2:16 a.m., ketmar wrote:
 On Sun, 15 Mar 2015 16:32:25 +1300, 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.
this never helps. what sense of having "documentation" like "enum SomeType" for `enum SomeType`?
=20 Ok enums probably wouldn't be. I'm more thinking of struct/classes/unions functions/methods properties and global variables. Maybe even head of module.
but that will be the same. formater has no AI, so it can't write=20 documentation. ;-) and copy-pasted definitions is not a documentation at=20 all. i've seen alot of doxygen examples of that, and it doesn't help a=20 little, i have to dig into sources anyway. either author did proper=20 documenting, or leave it as is, as generating stubs will not help.=
Mar 15 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 16/03/2015 2:33 a.m., ketmar wrote:
 On Mon, 16 Mar 2015 02:19:08 +1300, Rikki Cattermole wrote:

 On 16/03/2015 2:16 a.m., ketmar wrote:
 On Sun, 15 Mar 2015 16:32:25 +1300, 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.
this never helps. what sense of having "documentation" like "enum SomeType" for `enum SomeType`?
Ok enums probably wouldn't be. I'm more thinking of struct/classes/unions functions/methods properties and global variables. Maybe even head of module.
but that will be the same. formater has no AI, so it can't write documentation. ;-) and copy-pasted definitions is not a documentation at all. i've seen alot of doxygen examples of that, and it doesn't help a little, i have to dig into sources anyway. either author did proper documenting, or leave it as is, as generating stubs will not help.
Yeah I know. Its kinda why I said it could be out of scope. After all, this is the kind of thing you expect of IDE's. But it also could have pretty good fit here as well. To try and push best practice documentation wise.
Mar 15 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 16 Mar 2015 02:37:46 +1300, Rikki Cattermole wrote:

 On 16/03/2015 2:33 a.m., ketmar wrote:
 On Mon, 16 Mar 2015 02:19:08 +1300, Rikki Cattermole wrote:

 On 16/03/2015 2:16 a.m., ketmar wrote:
 On Sun, 15 Mar 2015 16:32:25 +1300, 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.
this never helps. what sense of having "documentation" like "enum SomeType" for `enum SomeType`?
Ok enums probably wouldn't be. I'm more thinking of struct/classes/unions functions/methods properties and global variables. Maybe even head of module.
but that will be the same. formater has no AI, so it can't write documentation. ;-) and copy-pasted definitions is not a documentation at all. i've seen alot of doxygen examples of that, and it doesn't help a little, i have to dig into sources anyway. either author did proper documenting, or leave it as is, as generating stubs will not help.
=20 Yeah I know. Its kinda why I said it could be out of scope. After all, this is the kind of thing you expect of IDE's. But it also could have pretty good fit here as well. To try and push best practice documentation wise.
on the other side, i can see a sense in generating "stubs" for functions=20 and templates, as it's somewhat boring to copypaste argument names. not=20 that it's a big deal, but... ;-)=
Mar 15 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Sun, 15 Mar 2015 13:47:26 +0000, ketmar wrote:

 on the other side, i can see a sense in generating "stubs" for functions
 and templates, as it's somewhat boring to copypaste argument names. not
 that it's a big deal, but... ;-)
i mean ddoc stubs, of course. ;-)=
Mar 15 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Mar 15 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 16/03/2015 8:08 a.m., Walter Bright wrote:
 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.
It is yes. No disagreement there. Its just a real pain to create these stubs by hand. Atleast this way, people will moan about documentation being empty and it'll seem less work to do.
Mar 15 2015
next sibling parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Monday, 16 March 2015 at 00:13:58 UTC, Rikki Cattermole wrote:
 On 16/03/2015 8:08 a.m., Walter Bright wrote:
 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.
It is yes. No disagreement there. Its just a real pain to create these stubs by hand. Atleast this way, people will moan about documentation being empty and it'll seem less work to do.
At any rate, that's not a job for a code formatter. Code formatters should mess around with whitespace, maybe with comment styles(e.g. fixing the border of multiline comments) - and that's it. Adding comments it's way out of it's scope. And if you need a more concrete reason - a code formatter should be able to act as a filter - put code in STDIN, get formatted code from STDOUT. So, let's say I mark the function without it's docs, and send it to dfmt. Should dfmt add docs to it? The docs are already there, but dfmt cannot tell because it only got the function itself... The traditional place to inject documentation stubs is in the snippets engine - where it is acceptable to automatically add code. And if want to check for missing docs, you can always use dscanner --styleCheck(https://github.com/Hackerpilot/Dscanner#style-check) to find them, instead of relying on people to complain about them.
Mar 15 2015
parent "Brian Schott" <briancschott gmail.com> writes:
On Monday, 16 March 2015 at 01:52:57 UTC, Idan Arye wrote:
 And if you need a more concrete reason - a code formatter 
 should be able to act as a filter - put code in STDIN, get 
 formatted code from STDOUT.
There are probably some languages where this will work, such as Lua, but this will never work for D. You need a parser to do formatting properly.
Mar 15 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-03-16 01:13, Rikki Cattermole wrote:

 Its just a real pain to create these stubs by hand. Atleast this way,
 people will moan about documentation being empty and it'll seem less
 work to do.
This should be done by the editor. -- /Jacob Carlborg
Mar 17 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 17 Mar 2015 10:36:47 +0100, Jacob Carlborg wrote:

 On 2015-03-16 01:13, Rikki Cattermole wrote:
=20
 Its just a real pain to create these stubs by hand. Atleast this way,
 people will moan about documentation being empty and it'll seem less
 work to do.
=20 This should be done by the editor.
and code formatting too...=
Mar 17 2015
prev sibling next sibling parent "Alaksiej =?UTF-8?B?U3RhbmtpZXZpxI0i?= <harald_zealot tut.by> writes:
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!!!
Mar 14 2015
prev sibling next sibling parent "anonymous" <aqzsedrftgyhujik dfghjk.fi> writes:
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.
Mar 15 2015
prev sibling next sibling parent "Idan Arye" <GenericNPC gmail.com> writes:
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).
Mar 15 2015
prev sibling next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
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?
clang-format has a pretty extensive set: http://clang.llvm.org/docs/ClangFormatStyleOptions.html I don't think all of that is necessary however. When I started using clang-format I just looked at the predefined styles (LLVM, Google, Chromium, Mozilla, Webkit) and picked the one I liked the most and didn't stress the details. I guess what I'm saying is I'd like a bunch of predefined styles. I don't want to wade through 50 options to make my own style. dfmt would, of course, need to support expressing all the predefined styles and all of those differences should have options.
Mar 15 2015
parent "Idan Arye" <GenericNPC gmail.com> writes:
On Monday, 16 March 2015 at 02:16:18 UTC, Brad Anderson wrote:
 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?
clang-format has a pretty extensive set: http://clang.llvm.org/docs/ClangFormatStyleOptions.html I don't think all of that is necessary however. When I started using clang-format I just looked at the predefined styles (LLVM, Google, Chromium, Mozilla, Webkit) and picked the one I liked the most and didn't stress the details. I guess what I'm saying is I'd like a bunch of predefined styles. I don't want to wade through 50 options to make my own style. dfmt would, of course, need to support expressing all the predefined styles and all of those differences should have options.
That's why dfmt should be able to read the configuration from a file(clang-format has that option). That way, all these predefined styles can simply be style files you can download - no need to make separate paths for predefined styles and custom styles. That being said - I'm against having predefined styles bundled with dfmt(either as separate style files or embedded into the executable). The only build-in style should be the one true style. While there are enough D projects out there to require dfmt to be configurable, we don't have multiple commonly accepted styles like C or C++, and I see no point in encouraging such a thing...
Mar 16 2015
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-03-15 00:15, Brian Schott wrote:

 What am I missing?
* Ideally, any space that is optional in the language should be configurable * Newlines between functions/structs/classes and so on * Preserve grouping of variable declarations, i.e. int a; int b; int foo; int bar; -- /Jacob Carlborg
Mar 17 2015
prev sibling next sibling parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 03/15/2015 12:15 AM, Brian Schott wrote:
 What am I missing?
Sorry haven't read the whole thread. I think there should be an option (even default on) to allow small single line functions. This can sometimes be fairly annoying. For example when writing range adapters, see https://github.com/D-Programming-Language/phobos/blob/77152b537b4cc6482d6181c17866475f1115beb9/std/range/package.d#L216. bool empty() { return arr.length == 0; } T opIndex(size_t i) { return arr[idx]; } T front() { return arr[0]; } void popFront() { arr = arr[1 .. $]; } This currently expands to 20 lines of code. bool empty() { return arr.length == 0; } T opIndex(size_t i) { return arr[idx]; } T front() { return arr[0]; } void popFront() { arr = arr[1 .. $]; }
Mar 22 2015
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/22/15 10:05 AM, Martin Nowak wrote:
 On 03/15/2015 12:15 AM, Brian Schott wrote:
 What am I missing?
Sorry haven't read the whole thread. I think there should be an option (even default on) to allow small single line functions. This can sometimes be fairly annoying. For example when writing range adapters, see https://github.com/D-Programming-Language/phobos/blob/77152b537b4cc6482d6181c17866475f1115beb9/std/range/package.d#L216. bool empty() { return arr.length == 0; } T opIndex(size_t i) { return arr[idx]; } T front() { return arr[0]; } void popFront() { arr = arr[1 .. $]; }
Agreed. Also, a thought: a mixin sounds like a nice way to generate such boilerplate if frequent. -- Andrei
Mar 22 2015
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-03-22 18:05, Martin Nowak wrote:

 Sorry haven't read the whole thread.
 I think there should be an option (even default on) to allow small
 single line functions.

 This can sometimes be fairly annoying. For example when writing range
 adapters, see
 https://github.com/D-Programming-Language/phobos/blob/77152b537b4cc6482d6181c17866475f1115beb9/std/range/package.d#L216.

 bool empty() { return arr.length == 0; }
 T opIndex(size_t i) { return arr[idx]; }
 T front() { return arr[0]; }
 void popFront() { arr = arr[1 .. $]; }
I really don't like this way of formatting code. Although I would like that the D syntax allowed to drop the curly braces, like with if-satements. That would result in much nicer one-liner functions. -- /Jacob Carlborg
Mar 23 2015
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jacob Carlborg:

 Although I would like that the D syntax allowed to drop the
 curly braces, like with if-satements. That would result
 in much nicer one-liner functions.
See: https://issues.dlang.org/show_bug.cgi?id=7176 Bye, bearophile
Mar 23 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-03-23 10:47, bearophile wrote:

 See:
 https://issues.dlang.org/show_bug.cgi?id=7176
Exactly. -- /Jacob Carlborg
Mar 23 2015
prev sibling parent reply "Casper =?UTF-8?B?RsOmcmdlbWFuZCI=?= <shorttail hotmail.com> writes:
On Sunday, 22 March 2015 at 17:05:27 UTC, Martin Nowak wrote:
 I think there should be an option (even default on) to allow 
 small
 single line functions. (snip)
Perhaps it's too much to wish for, but I think the editor would be the better place for this. IntelliJ IDEA can display short methods as single line. They're still multiline in the source, but on screen they're nice. They used a similar thing with anonymous classes in Java prior to lambdas hitting the language, making single method anonymous classes look almost like the lambdas do today.
Mar 23 2015
parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 03/23/2015 10:55 AM, "Casper =?UTF-8?B?RsOmcmdlbWFuZCI=?=
<shorttail hotmail.com>" wrote:
 
 Perhaps it's too much to wish for, but I think the editor would be the
 better place for this. IntelliJ IDEA can display short methods as single
 line. They're still multiline in the source, but on screen they're nice.
 They used a similar thing with anonymous classes in Java prior to
 lambdas hitting the language, making single method anonymous classes
 look almost like the lambdas do today.
Why would you write out code that everyone reads abbreviated? Source code is still targeted at human readability not machine parsing.
Mar 23 2015
prev sibling parent reply Shammah Chancellor <anonymous coward.com> writes:
On 2015-03-14 23:15:34 +0000, Brian Schott said:

 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?
A way to configure this and have it look for the most relevant `.dfmtcfg` file! :) That is to say, make it look up from the current directory recursively until it finds a config file, and use that. This will greatly help people who are contributing to the same project keep a consistent format. Also, Hard and soft limit for line length causes an exception to be thrown when I tried it. -Shammah
Mar 27 2015
parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 03/27/2015 04:30 PM, Shammah Chancellor wrote:
 What am I missing?
A way to configure this and have it look for the most relevant `.dfmtcfg` file! :) That is to say, make it look up from the current directory recursively until it finds a config file, and use that. This will greatly help people who are contributing to the same project keep a consistent format. Also, Hard and soft limit for line length causes an exception to be thrown when I tried it. -Shammah
I proposed to use .editorconfig for this, as it already tries to standardize most of the configurations. https://github.com/Hackerpilot/dfmt/issues/122
Mar 27 2015