dfmt options
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?
Re: dfmt options
On Sat, 14 Mar 2015 23:15:34 +, 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?
optional space before arguments in function declaration, if you please.
i.e.:
void foo();
vs
void foo ();
signature.asc
Description: PGP signature
Re: dfmt options
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.
Re: dfmt options
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.
Re: dfmt options
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.
Re: dfmt options
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.
Re: dfmt options
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.
Re: dfmt options
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.
Re: dfmt options
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
Re: dfmt options
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.
}
Re: dfmt options
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
Re: dfmt options
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.
Re: dfmt options
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.
Re: dfmt options
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.
Re: dfmt options
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
Re: dfmt options
"Brian Schott" wrote in message news:iobidfcyoneyxrzkh...@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 ];
Re: dfmt options
"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.
Re: dfmt options
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.
Re: dfmt options
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.
Re: dfmt options
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.
Re: dfmt options
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!!!
Re: dfmt options
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.
Re: dfmt options
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
Re: dfmt options
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.
Re: dfmt options
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.
Re: dfmt options
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.
Re: dfmt options
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.
Re: dfmt options
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?
Re: dfmt options
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.
Re: dfmt options
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.
Re: dfmt options
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
Re: dfmt options
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, > > 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. 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? signature.asc Description: PGP signature
Re: dfmt options
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`? signature.asc Description: PGP signature
Re: dfmt options
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.
Re: dfmt options
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
Re: dfmt options
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. signature.asc Description: PGP signature
Re: dfmt options
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.
Re: dfmt options
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.
Re: dfmt options
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. > > 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 and templates, as it's somewhat boring to copypaste argument names. not that it's a big deal, but... ;-) signature.asc Description: PGP signature
Re: dfmt options
On Sun, 15 Mar 2015 13:47:26 +, 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. ;-) signature.asc Description: PGP signature
Re: dfmt options
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! signature.asc Description: PGP signature
Re: dfmt options
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...
Re: dfmt options
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).
Re: dfmt options
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.
Re: dfmt options
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.
Re: dfmt options
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.
Re: dfmt options
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.
Re: dfmt options
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
Re: dfmt options
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
Re: dfmt options
On Sun, 15 Mar 2015 13:23:09 -0700, Jonathan M Davis via Digitalmars-d wrote: > Yes, sorry. Forcing is too strong a word. However, if we're putting out > an official formatting tool which has no configurability, unless we're > telling folks that it's specifically for the official source code and then it will be forken in the blink of an eye, and turned into configurable, with "phobos" preset. and then nobody will use bundled dfmt, 'cause there will be no reason to, as forked one will be able to do anything bundled can and more. signature.asc Description: PGP signature
Re: dfmt options
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.
Re: dfmt options
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.
Re: dfmt options
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.
Re: dfmt options
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.
Re: dfmt options
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.
Re: dfmt options
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...
Re: dfmt options
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
Re: dfmt options
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
Re: dfmt options
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
Re: dfmt options
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
Re: dfmt options
On Tue, 17 Mar 2015 10:36:47 +0100, Jacob Carlborg wrote: > 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. and code formatting too... signature.asc Description: PGP signature
Re: dfmt options
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 .. $];
}
Re: dfmt options
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
Re: dfmt options
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
Re: dfmt options
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
Re: dfmt options
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.
Re: dfmt options
On 2015-03-23 10:47, bearophile wrote: See: https://issues.dlang.org/show_bug.cgi?id=7176 Exactly. -- /Jacob Carlborg
Re: dfmt options
On 03/23/2015 10:55 AM, "Casper =?UTF-8?B?RsOmcmdlbWFuZCI=?= " 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.
Re: dfmt options
On 2015-03-14 23:15:34 +, 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
Re: dfmt options
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
