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