Wed Oct 17 - Avoiding Code Smells by Walter Bright

[unprotected-entity]

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 ;-)