Best Practices for Internal Package Structure

[Sven R. Kunze]

On 06.04.2016 01:47, Chris Angelico wrote:
> 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.

Well said.

The definition of purpose and concept are blurry, though. So, what is 
within the boundary of a concept is hard to define.


@Steven
You might not understand the purpose of the guideline. That's what makes 
them so valuable. It's hard to get them right and it's hard to 
understand them if you don't have any experience with them.



An attempt of an explanation (which maybe in itself not 100% correct): 
there are two different forces acting on the source code:

1) make it short and concise (the 2-pages guideline)
2) keep conceptually close things together (cf. Chris)

So, there's always a bargaining of what can be put in/removed from a 
module in the first place:

"just these 14 lines, please; we need that feature"
"but the module already has 310 lines"
"only this one last one, please; it belongs here"
"but it's an if-else and another def; nasty nesting and more complexity"
"hmm, what if we remove those 5 over here? we don't need them anymore"
"really? then, we can remove 2 superfluous newlines and 2 import lines 
as well"
"I could even squeeze those 14 lines to 10 using dict comprehensions"
"that's even more readable; +1 line, that's okay"

Life is full of compromises.

This guideline is more about discussing, shaping existing code and 
extracting the essence (with yourself or with colleagues) to keep things 
on a usable level.

Best,
Sven