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

Jeremy Powers via Digitalmars-d digitalmars-d at puremagic.com
Thu Mar 19 15:13:51 PDT 2015


On Thu, Mar 19, 2015 at 3:03 PM, Walter Bright via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:
>
>
> Accessor functions that merely return a field variable are bull anyway.
>

I would recommend against opening up this debate.  Suffice it to say that
this is a well established pattern that many people use; there is well-trod
ground arguing both sides.


>     int foo;
>     int getFoo() { return foo; }
>

A valid reason for doing things like this is future-proof encapsulation.
You can change the internal foo to be something entirely different, and the
external api never changes (assuming 'foo' is private).


As for the documentation - yeah, don't write docs that duplicate what is
there in the method signature.  In the above example, documentation should
explain what foo actually is, and why you might need it.  Otherwise is just
duplicate boilerplate that should be generated by the doc generator.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20150319/685eaba5/attachment-0001.html>


More information about the Digitalmars-d mailing list