• Timothee Cour (33/33) Feb 21 2018 from my perspective it makes sense to split a module M into submodules
• rikki cattermole (3/6) Feb 21 2018 Soft 1k, 2-3k hard limit.
• Timon Gehr (4/8) Feb 22 2018 I don't think this particular point is true. Splitting can actually make...
• H. S. Teoh (22/31) Feb 22 2018 +1.

Timothee Cour <thelastmammoth gmail.com> writes:

from my perspective it makes sense to split a module M into submodules
A, B when:
* M is large
* there's little interaction between A and B (eg only few symbols from
A are needed in B and vice versa)
* A and B are logically grouped (that is domain specific)
* it doesn't turn into an extreme (1 function per module)

Advantages of splitting:
* easier to review
* easier to edit (no need to scroll much to see entirety of module
we're editing)
* less pollution from top-level imports as they only affect submodule
(likewise with top-level attributes etc)
* more modular
* doesn't affect existing code since `import M` will continue to work
after M is split into a package
* less memory when using separate compilation
* allows fine-grained compiler options (eg we can compile B with `-O` if needed)
* allows to run unittests just for A instead of M
* allows selective import in client to avoid pulling in too many
dependencies (see arguments that were made for std.range.primitives)

Disadvantages of splitting:
* more files; but not sure why that's a problem so long we don't go
into extremes (eg 1 function per module or other things of bad taste)

---
while working on https://github.com/dlang/phobos/pull/6178 I had
initially split M:std.array into submodules:
A:std.array.util (the old std.array) and B:std.array.static_array
(everything added in the PR)
IMO this made sense according to my above criteria (in this case there
was 0 interaction between A and B), but the reviewers disagreed with
the split.

So, what are the guidelines?

rikki cattermole <rikki cattermole.co.nz> writes:

On 22/02/2018 8:13 PM, Timothee Cour wrote:
 from my perspective it makes sense to split a module M into submodules
 A, B when:
 * M is large

Soft 1k, 2-3k hard limit.

At this point either your scope is good, or you need to subdivide it again.

Timon Gehr <timon.gehr gmx.ch> writes:

On 22.02.2018 08:13, Timothee Cour wrote:
 Advantages of splitting:
 ...
 * easier to edit (no need to scroll much to see entirety of module
 we're editing)

I don't think this particular point is true. Splitting can actually make 
editing slightly harder. Scrolling is an inefficient way to find the 
definition to edit; just search the file for the definition.

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Thu, Feb 22, 2018 at 03:53:59PM +0100, Timon Gehr via Digitalmars-d wrote:
 On 22.02.2018 08:13, Timothee Cour wrote:
 Advantages of splitting:
 ...
 * easier to edit (no need to scroll much to see entirety of module
 we're editing)

 
 I don't think this particular point is true. Splitting can actually
 make editing slightly harder. Scrolling is an inefficient way to find
 the definition to edit; just search the file for the definition.

+1.

A worthwhile coding editor will have built-in functionality to search
for symbols and making bookmarks.

In Vim, I usually mark several important places in the code, e.g., a
mark on the class/struct definition that I'm working on, another mark on
a related template, another mark on the function, another mark on the
associated unittest, etc.. This lets me jump to any relevant place in
two keystrokes, without needing to care exactly where it is in the file.
I also have a semi-standard assignment of marks, and update them as I go
along, so I can always switch between different parts of the
functionality I'm working on.  For looking up other things, searching
for symbols and ctags with jump-to-definition is invaluable.

Also, Vim's ability to split the window at any time is invaluable: it
lets me, for example, work on a unittest while having the function body
in view or vice versa. Or jump between the two and work on two places in
the same file at the same time.

Any editor/IDE incapable of such basic functionality ought to be thrown
out the window and replaced with something more usable.


T

-- 
GEEK = Gatherer of Extremely Enlightening Knowledge