Hello, not documenting at first is not really a question of laziness or so, as things are still moving around you absolutely need this agility; a good design layout between theory and stable state will refactored discussed a thousand times; that what I expect from engineers; filling the gaps between assumptions and reality.
And for me-self throw vs no throw is important language information and part of internal behaviors; to clarify, for instance, would be more useful to have such indicator rather than having having abstract and interface which are cumbersome; same as the extra public keyword; you can do without especially with the new traits construct. Best. On Wed, Apr 3, 2019 at 9:42 AM Rowan Collins <rowan.coll...@gmail.com> wrote: > On Wed, 3 Apr 2019 at 17:27, M. W. Moe <mo.mu....@gmail.com> wrote: > > > yes this is very true; but usually on complex design with a lot of folks > > working on it you start coding before documenting; > > > > > If it's just syntax that doesn't change behaviour, it's really just > documentation anyway, and if people are so desperate to dig into the code > that they can't write a minimal docblock (or so lazy that they won't), how > likely is it that they'll correctly add this new indicator? > > If you want to be explicit, don't put off docblocks until later (writing > them before you've even implemented the function can be a great way of > clarifying your design), and use an IDE or CI tool that will tell you when > they're missing or incorrect. > > Regards, > -- > Rowan Collins > [IMSoP] >
