Best Practices for Internal Package Structure

[Chris Angelico]

On Wed, Apr 6, 2016 at 9:29 AM, Steven D'Aprano <steve at pearwood.info> wrote:
> As we speak, I have 28 text editor windows open. Not all of them are Python
> code, but among those which are, I have:
> [chomp line number counts]

I was about to say "Wow, I don't have anything LIKE that many text
editor windows open"... but then went and counted. Uhh, 21 tabs up in
SciTE. So, yeah. Same ballpark. Like you, though, some of them aren't
code at all, and of those that are, there's several languages
represented; they range from a fully-functional 19 line file (not
stubby or anything) to a 2026-line module that actually does have some
"maybe X, Y, and Z could be broken out into a separate file" comments.
It's not excessive at the moment, but those few are stretching the
file's stated purpose (they're used primarily by other functions in
the file, though, and there's no better place for them).

Generally, I refactor code not because the files are getting "too
large" (for whatever definition of that term you like), but because
they're stretching the file's concept. Every file should have a
purpose; every piece of code in that file should ideally be supporting
exactly that purpose. This file over here handles the socket
connection to the server - it has functions to connect and disconnect,
to cope with servers that don't declare their encodings, to process
lines of text the server sends and figure out what to do with them, to
manage keep-alives, and so on. That file is all about the GUI - it
creates a window on screen, has event handlers, deals with fonts,
tracks user interaction so it can flag unread information, and has a
small function "connect/disconnect" which handles the UI side of
things and then calls a function from the connection module. One of
these files is 485 lines long; the other is 2026 lines long. Neither
of them needs to be refactored, because they both fit their goals.

ChrisA