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?

On Sat, 14 Mar 2015 23:15:34 +0000, 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 ();

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.

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.

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.

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.

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.

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.

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

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