Best Practices for Internal Package Structure

[Sven R. Kunze]

On 05.04.2016 19:59, Chris Angelico wrote:
> On Wed, Apr 6, 2016 at 3:38 AM, Sven R. Kunze <srkunze at mail.de> wrote:
>>> Your package is currently under 500 lines. As it stands now, you could
>>> easily flatten it to a single module:
>>>
>>> bidict.py
>>
>> I don't recommend this.
>>
>> The line is blurry but 500 is definitely too much. Those will simply not fit
>> on a 1 or 2 generous single screens anymore (which basically is our
>> guideline). The intention here is to always have a bit more of a full screen
>> of code (no wasted pixels) while benefiting from switching to another file
>> (also seeing a full page of other code).
> Clearly this is a matter of opinion. I have absolutely no problem with
> a 500-lne file. As soon as you force people to split things across
> files, you add a new level of indirection that causes new problems.

Guidelines. No forcing.

> I'd rather keep logically-related code together rather than splitting
> across arbitrary boundaries;

That's a good advice and from what I can see bidict adheres to that. ;)

> you can always search within a file for the bit you want.

If you work like in the 80's, maybe. Instead of scrolling, (un)setting 
jumppoints, or use splitview of the same file, it's just faster/easier 
to jump between separate files in todays IDEs if you need to jump 
between 4 places within 3000 lines of code.

> When you split a file into two, you duplicate the
> headers at the top (imports and stuff), so you'll split a 100-line
> file into two 60-line files or so. Do that to several levels in a big
> project and you end up with a lot more billable lines of code, but no
> actual improvement.

Who cares about the imports? As I said somewhere else in my response, 
it's hidden from sight if you use a modern IDE. We call that folding. ;)

Who bills lines of code? Interesting business model. ;)

> I guess that's worth doing - lovely billable hours
> doing the refactoring,

Refactoring is not just splitting files if that concept is new to you.

Refactoring it not an end to itself. It serves a purpose.

> more billable hours later on when you have to
> read past the migration in source control ("where did this line come
> from" gets two answers all the time), and more billable hours dealing
> with circular imports when two fragments start referring to each
> other. Sounds like a plan.

It appears to me as if you like messy code then. ;)

Best,
Sven