Enhancement: issue error on all public functions that are missing ddoc sections

w0rp via Digitalmars-d digitalmars-d at puremagic.com
Fri Mar 20 04:54:20 PDT 2015


On Thursday, 19 March 2015 at 22:04:01 UTC, Walter Bright wrote:
> On 3/19/2015 2:43 AM, deadalnix wrote:
>> Here is what will pass review :
>
> Presumably the reviewers will have some common sense and taste.
>
>> class User {
>>    /**
>>     * Accessor to get the id of the user.
>>     *
>>     * @return : the id of the user
>>     */
>>    uint getUserID() { ... }
>>
>>    /**
>>     * Accessor to get the name of the user.
>>     *
>>     * @return : the name of the user
>>     */
>>    string getName() { ... }
>
> Accessor functions that merely return a field variable are bull 
> anyway.
>

Hear, hear! I start with first with...

public string name;

Then if I really want to change the way the value is assigned or 
maybe add in some validation, possibly with contracts, I use 
@property.

(This is only for things which are supposed to be part of the 
public API anyway.)

I would still document the property, though. I feel I need to 
justify why every member exists in a struct or class. That's 
mainly a data layout concern, and that's just how I happen to 
feel about it.


More information about the Digitalmars-d mailing list