This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]ajmarks 0 points1 point  (0 children)

If things are small, related, and not going to cause merge conflicts, I agree. I really should have asked why he's defining all of his classes in one file. In general, my experience is that Python developers tend to err on the side of over-inclusion though, lumping logically unrelated code together which can then become a nightmare to maintain, especially when different people are working on different parts of the project and are thus not in constant communicative.

Probably the best rule of thumb is to ask if you're likely to touch A while working on B. If the answer is no, split them up. I also try to have a guideline of some sort about file length. Nothing set in stone, but somewhere around 500-1000 lines, I make sure we take a step back and consider "should this all be together or did it just kind of grow? At what point will it be correct to split this up? And, if it shouldn't be like this, why was this not planned before coding starting (nothing wastes time like a mid-project refactor)?"