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 /

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