On Saturday, 21 February 2015 at 20:46:09 UTC, Kenny wrote:
I like D modules and it's a major point in the list of major
points why I like D (there is also the second not so nice
wft-list but it's for another post). I'm annoyed with C++
includes and I'm tired to create 2 files every time when I need
to add something new to the project... But I must admit that
one
thing I like in header files is that it is a convenient way to
read public interfaces.
In D we have interface specification and implementation in a
single file and also one approach with unit testing is to put
them immediately after functions which makes writing unit tests
even more easy task (and I like it very much) but again it makes
the gaps between declarations even wider.
So, what are the common approaches for reading public interfaces
in D programs? Especially it would be great to see the answers
of
developers who work with more or less big codebases.
The few possible solution I'm thinking about at the moment:
a) Provide D interfaces for corresponding classes (but probably
it's only for more or less complex abstractions and also I won't
use it for Vector3D, also very often I use just regular
functions).
b) Write DDocs and read documentation. The problem here is that
I'm going to use D only for my own projects and in the last time
I tend to write less documentation, for example I do not write
it
for the most methods of Vector3D.
c) Do nothing special, just write D modules and try to figure
out
public interfaces reading its code. Maybe it works in practice.
Thanks,
Artem.
You can also fold all the function bodies in your editor, this
helps me to read massive sources.
