Re: One module per class, bad idea?

Erik Johnson wrote:
The file has now grown into a 6800 line beast (including docstring,
whitespace, and CVS history). Pretty much any time we implement some new
functionality, there are at least a few changes in that file. When you have
multiple developers working on different projects, and they all need to be
making changes to that file, the chances for someone making a merge error
goes up. So, we are obviously at a point where that file needs to be split
up, but there are lots of other files that import and use the one file, so
it is a task that has been put off. In retrospect, I wish I has started
things under a one class per file strategy, but at the time, it didn't make
a lot of sense to split those things up and I didn't anticipate the code
getting that big.

Refactor NOW. I realize this is not as easy to do for a large team
than it is for a solo programmer like me, but ISTM people tend to
overestimate the cost and underestimate the benefit of it. And I've
seen some pretty bad excuses besides for not doing it. (But how can we
refactor when we have programmers checking stuff out all the time? Um,
how bout doing it during off hours? But it's too much to do in a
weekend! Which only goes to show you you've let it go too far.
Refactor in small doses.)

I have two files ~1000 lines that are marked as "these files are
getting too big". (They currently define 20 and 24 classes--though in
fairness the one with 24 has a bunch of small mixins.) Soon as this
overloaded holiday season is over, they're getting broken up.


So... there's no magic "one size fits all" answer here - do what makes
sense.

As Carl points out, decent editors should be able to handle dispaying
different files.

Actually, I pointed out that decent editors should be able to handle
displaying the same file twice. In case you want to edit two different
points of the same file side-by-side.


Carl Banks

.