On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole
wrote:
On 01/11/2018 2:25 AM, 12345swordy wrote:
On Wednesday, 31 October 2018 at 13:22:28 UTC, rikki
cattermole wrote:
On 01/11/2018 2:16 AM, 12345swordy wrote:
On Wednesday, 31 October 2018 at 05:42:26 UTC, Nicholas
Wilson wrote:
Running into such problems is a sign that your module is
too large, and should become a package.
I seen modules with more then thousand lines of code in the
Phobos library. What exactly consist a module of being "too
large"? If having two classes in a module with around
200-300 lines of code "too large"?
We have been splitting Phobos modules up:
std.algorithm and most recently std.datetime
They were MASSIVE as in 30k+ LOC massive.
That's nice.
Again what consist of a module of being "too large"?
That seems to me that more of a art then a science.
Because it is.
My rules (which tend to be a little stricter than most peoples)
are:
Soft split 1k LOC, hard split 3k LOC without a very good reason
not to.
But at the end of the day, it just depends on the scope of the
module. Is it getting to large? If so, split.
I really do disagree.
It's is not at all, about LOC.
It is about clean architecture.
D module's do not promote clean architecture. Why? Because
private state is exposed to all code within a module. What will
happen to clean architecture, when you make that available to
programmers? Well.. we get phobos like architecture.
Another thing to look for, is signs of code smell. I would
include in this, unit tests calling private methods (which seems
to be a popular thing for D programmers to do). Some will
disagree that this is a code smell, but I have yet to see a good
argument for why it is not.
Forget LOC. Look for good architecture, decoupling, modularity,
encapsulation, information hiding....etc..etc... again, sadly,
these concepts are not directly promoted when writing modules in
D, since the module exposes everything to everything else in the
module - and programmers will surely make use of any convenient
hack that avoids them having to think about good architecture ;-)
