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
--
https://mail.python.org/mailman/listinfo/python-list