If I split one class into two classes should both classes have history in source control tracing back to the original class that contained both; or should the new class be added as a new file without any history tracing back?
When splitting a large class into two similar sized parts this seems like the natural approach since the older versions of the combined class will have large amounts of relevant history for both descendents. When I’m just pulling one or two methods out to create a helper class, having the complete history for the new class be >90% changes in the parent that affected code that wasn’t split out seems like a recipe for confusion in the future.
6
It’s much easier to ignore some history later than to try to splice it back in. In general you want to favor the least destructive option. People primarily review source control history for three reasons:
- To find out which change introduced a bug.
- To discern the reasons why a section of code is in there.
- To find out what has changed since the last release or the last time you updated.
Copying history for a split file contributes little if any confusion for any of those use cases. The worst that happens is you have to sift through some irrelevant commits, and you generally have to do that anyway. On the other hand, not having the history past a certain point makes the first two use cases much more difficult.
I’m not sure this type of thing is necessary.
Your initial check in of the new class might say “Split ClassX and created ClassY and ClassZ based on it because…..”
If a user really needs to trace back they can still find the original history.
5
That’s what code repositories are for (Git, Subversion, et.al.).
Having maintained some very, very old code I can say that one of the worst things you can do is leave “history” in code files.
Ancient, esoteric code fragments and cruft is not documentation.
A functioning, in production code base is not a museum.
Every line of code costs time and money to maintain, every line; including non-functioning, irrelevant, obsolete ones.
Each successive code change makes all earlier ones less relevant, less informative, and harder to understand.
How can I explain it… I want to take flying lessons, but wait! What’s this about the Wright Brothers? Oh, I need to stop and learn all about how the Wright Flyer worked and after too much time wasted realize that explicit details about how that thing worked are totally irrelevant to using this airplane. And what in the wide world of sports is this old rusted dohickey in the instrument panel?
In the final analysis Anything I need to know is incorporated in the current design.
1