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.

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.

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.

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.

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.

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

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

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

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

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