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

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?

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`?

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.

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

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.

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

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

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.