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

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.

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.

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.

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

"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
]; 

"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. 

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.

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.

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.