Jump to page: 1 26  
Page
Thread overview
Enhancement: issue error on all public functions that are missing ddoc sections
Mar 18, 2015
Walter Bright
Mar 18, 2015
Jacob Carlborg
Mar 18, 2015
Walter Bright
Mar 18, 2015
Jacob Carlborg
Mar 19, 2015
Jacob Carlborg
Mar 19, 2015
deadalnix
Mar 19, 2015
Brian Schott
Mar 19, 2015
Walter Bright
Mar 19, 2015
Jeremy Powers
Mar 19, 2015
bachmeier
Mar 20, 2015
deadalnix
Mar 20, 2015
Walter Bright
Mar 20, 2015
Kagamin
Mar 20, 2015
Walter Bright
Mar 19, 2015
deadalnix
Mar 20, 2015
David Gileadi
Mar 20, 2015
Walter Bright
Mar 20, 2015
w0rp
Mar 20, 2015
Jonathan M Davis
Mar 21, 2015
Walter Bright
Mar 21, 2015
deadalnix
Mar 19, 2015
deadalnix
Mar 19, 2015
Walter Bright
Mar 19, 2015
deadalnix
Mar 20, 2015
Jonathan M Davis
Mar 20, 2015
Walter Bright
Mar 18, 2015
Brian Schott
Mar 18, 2015
Baz
Mar 19, 2015
Walter Bright
Mar 19, 2015
Kagamin
Mar 19, 2015
Don
Mar 19, 2015
Walter Bright
Mar 20, 2015
Jacob Carlborg
Mar 19, 2015
Benjamin Thaut
Mar 22, 2015
Martin Nowak
Mar 22, 2015
Benjamin Thaut
Mar 19, 2015
Gary Willoughby
Mar 19, 2015
Charles
Mar 19, 2015
w0rp
Mar 20, 2015
Walter Bright
Mar 23, 2015
Brad Roberts
Mar 24, 2015
Daniel Murphy
Mar 24, 2015
Kagamin
Mar 24, 2015
Dejan Lekic
Mar 24, 2015
Dejan Lekic
March 18, 2015
I'm fed up with this problem. It is actively hurting us every day.

https://issues.dlang.org/show_bug.cgi?id=14307

Anyone want to take this on? Shouldn't be particularly difficult.
March 18, 2015
On 2015-03-18 19:48, Walter Bright wrote:
> I'm fed up with this problem. It is actively hurting us every day.
>
> https://issues.dlang.org/show_bug.cgi?id=14307
>
> Anyone want to take this on? Shouldn't be particularly difficult.

I'm not so sure about this. I think there's a big chance that users will just add an empty documentation comment to silence the error.

I'm using a lint tool for Ruby that complains about this exact issue. Too often I just add an empty documentation comment do silence it. Although this mostly only happens for classes and modules, not for methods.

-- 
/Jacob Carlborg
March 18, 2015
On 3/18/2015 12:28 PM, Jacob Carlborg wrote:
>> Anyone want to take this on? Shouldn't be particularly difficult.
> I'm not so sure about this. I think there's a big chance that users will just
> add an empty documentation comment to silence the error.

Right, but then it becomes glaringly obvious in the Pull Request and easier to reject.


> I'm using a lint tool for Ruby that complains about this exact issue. Too often
> I just add an empty documentation comment do silence it. Although this mostly
> only happens for classes and modules, not for methods.

Why use the tool if you're going to ignore it?

There are several features in D that are meant for QA use, and are not necessarily to make the programmer's life easier. This would be another of them.

It's clear we have an endemic problem in the Phobos documentation, and just exhorting people to do better is not working. The bar needs to be raised on what is minimally acceptable.

Also, this feature would be enabled by a switch. Nobody has to use it, but I intend for it to be turned on for official D code.
March 18, 2015
On 2015-03-18 20:37, Walter Bright wrote:

> Why use the tool if you're going to ignore it?

It's tremendously useful for reporting other issues. I can configure the tool to not report the this issue but sometimes it's just easier to ignore.

-- 
/Jacob Carlborg
March 18, 2015
On 3/18/15 12:28 PM, Jacob Carlborg wrote:
> On 2015-03-18 19:48, Walter Bright wrote:
>> I'm fed up with this problem. It is actively hurting us every day.
>>
>> https://issues.dlang.org/show_bug.cgi?id=14307
>>
>> Anyone want to take this on? Shouldn't be particularly difficult.
>
> I'm not so sure about this. I think there's a big chance that users will
> just add an empty documentation comment to silence the error.

That won't pass review. -- Andrei

March 18, 2015
On Wednesday, 18 March 2015 at 18:48:53 UTC, Walter Bright wrote:
> I'm fed up with this problem. It is actively hurting us every day.
>
> https://issues.dlang.org/show_bug.cgi?id=14307
>
> Anyone want to take this on? Shouldn't be particularly difficult.

D-Scanner has had this feature for a while. Here's the list for Phobos:

http://dpaste.dzfl.pl/7d018aad2b10
March 18, 2015
On Wednesday, 18 March 2015 at 22:05:18 UTC, Brian Schott wrote:
> On Wednesday, 18 March 2015 at 18:48:53 UTC, Walter Bright wrote:
>> I'm fed up with this problem. It is actively hurting us every day.
>>
>> https://issues.dlang.org/show_bug.cgi?id=14307
>>
>> Anyone want to take this on? Shouldn't be particularly difficult.
>
> D-Scanner has had this feature for a while. Here's the list for Phobos:
>
> http://dpaste.dzfl.pl/7d018aad2b10

Based on the list: the task should be divided on a per module basis. Some modules have a lot of undocumented declaration that just need "ditto"; some others recquire specific knowledge (UTF), some other simply copy and paste (range things: popFront etc, eg "confere with..."). And among them it's not impossible that a few items should be private(testUrl1 testUrl2).

March 19, 2015
On 2015-03-18 20:43, Andrei Alexandrescu wrote:

> That won't pass review. -- Andrei

If that's the case, how did an undocumented symbol pass review in the first place?

-- 
/Jacob Carlborg
March 19, 2015
On 3/18/2015 3:05 PM, Brian Schott wrote:
> On Wednesday, 18 March 2015 at 18:48:53 UTC, Walter Bright wrote:
>> I'm fed up with this problem. It is actively hurting us every day.
>>
>> https://issues.dlang.org/show_bug.cgi?id=14307
>>
>> Anyone want to take this on? Shouldn't be particularly difficult.
>
> D-Scanner has had this feature for a while. Here's the list for Phobos:
>
> http://dpaste.dzfl.pl/7d018aad2b10

Thank you!
March 19, 2015
Indeed, dfmt and/or dfix can handle that just fine. They can also try to differentiate between public and private types.
« First   ‹ Prev
1 2 3 4 5 6