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"?

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.

On Wednesday, 31 October 2018 at 13:16:45 UTC, 12345swordy wrote:
> I seen modules with more then thousand lines of code in the Phobos library.

$ wc simpledisplay.d nanovega.d dom.d cgi.d
  14152   54984  443111 simpledisplay.d
  15289   63707  573986 nanovega.d
   7159   24473  187572 dom.d
   4132   16727  128299 cgi.d


lol

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.

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.

On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole wrote:

> But at the end of the day, it just depends on the scope of the module. Is it getting to large? If so, split.

Yup. LOC aren't a particulalry informative metric. Documentation, comments, unit tests, blanks, all contribute to it. Split by scope, by concept, by responsibility, by any implementation-relevant metric, not by LOC. As the joke goes, your word processor is doomed to fail once it also starts sending out emails...

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:
>>>> [...]
>>>
>>> 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.
Ok, you agree that it is subjective. Why is having more then one class per file "too large"?

On 01/11/2018 2:33 AM, Stanislav Blinov wrote:
> On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole wrote:
> 
>> But at the end of the day, it just depends on the scope of the module. Is it getting to large? If so, split.
> 
> Yup. LOC aren't a particulalry informative metric. Documentation, comments, unit tests, blanks, all contribute to it. Split by scope, by concept, by responsibility, by any implementation-relevant metric, not by LOC. As the joke goes, your word processor is doomed to fail once it also starts sending out emails...

Actually it is quite informative. As a code smell it does tell you pretty decently in my experience if your scope is too large or if you are in need of refactoring.

On 01/11/2018 2:35 AM, 12345swordy wrote:
> 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:
>>>>> [...]
>>>>
>>>> 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.
> Ok, you agree that it is subjective. Why is having more then one class per file "too large"?

It doesn't. It is a group of related symbols. If it doesn't have function bodies (e.g. extern(C++) or COM) I would call that module to have too small of a scope.

On Wednesday, 31 October 2018 at 13:37:07 UTC, rikki cattermole wrote:
> On 01/11/2018 2:33 AM, Stanislav Blinov wrote:
>> On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole wrote:
>> 
>>> But at the end of the day, it just depends on the scope of the module. Is it getting to large? If so, split.
>> 
>> Yup. LOC aren't a particulalry informative metric. Documentation, comments, unit tests, blanks, all contribute to it. Split by scope, by concept, by responsibility, by any implementation-relevant metric, not by LOC. As the joke goes, your word processor is doomed to fail once it also starts sending out emails...
>
> Actually it is quite informative. As a code smell it does tell you pretty decently in my experience if your scope is too large or if you are in need of refactoring.

Well, yes, it can be a litmus test, I guess. I meant to say that it isn't per se a deciding factor.