Best Practices for Internal Package Structure

[Chris Angelico]

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.
I'd rather keep logically-related code together rather than splitting
across arbitrary boundaries; you can always search within a file for
the bit you want. 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. I guess that's worth doing - lovely billable hours
doing the refactoring, 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.

ChrisA