Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
2  
If the classes are that alike, have you considered putting the common functionality into a base class, rather than duplicating code in this fashion? If ordinary refactoring is what you are trying to accomplish, the source control history should already be more than adequate, especially if you comment your changes. –  Robert Harvey Mar 20 '13 at 15:14
    
@RobertHarvey I'm generally thinking in terms of refactoring larger classes into smaller sized ones either because the initial design was poor and it was trying to do multiple things from the start, because repeatedly changing requirements gradually expanded a feature from one or two lines of code to several hundred at which point it's overdue for being separated into a helper/calculator class of some sort. –  Dan Neely Mar 20 '13 at 15:24
    
I'm curious in which VCS this is an option, and how. I know git blame has the -C option, but you specify that when you run blame later on. You can't turn it on or off somehow at commit time. –  Karl Bielefeldt Mar 20 '13 at 16:05
1  
@KarlBielefeldt I'm using SVN and am linking history by making a copy of the old file, renaming, and modifying it. This can all be done in a single checkin. –  Dan Neely Mar 20 '13 at 17:09
1  
"Hell yes!" - svn copy is perfect for this. You can even check the copy and two edit-downs in together. svn diff will show you how the split was done, and svn blame will give you full results for both files. –  Ross Patterson Mar 20 '13 at 23:08
show 1 more comment

3 Answers

up vote 4 down vote accepted

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:

  1. To find out which change introduced a bug.
  2. To discern the reasons why a section of code is in there.
  3. 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.

share|improve this answer
add comment

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.

share|improve this answer
    
I'm asking about when/if its utility exceeds it's confusion potential. Seeing blame results on ClassY.cs stop at where it was split off and then having to blame ClassX.cs to track down where a line of code came from is annoying even in the best case where ClassX.cs is still present in the current version of the application. If ClassX.cs was deleted after the split and you need to switch to an old version of the repository first the pain factor gets even higher. –  Dan Neely Mar 20 '13 at 15:46
    
I was going to put this in my answer but didn't. Do people really use version history in this way? This history is OBVIOUSLY useful to have, but in reality, I cannot remember the last time I needed to use version history to help me with a bug. I just figure out the issue and fix it. I cannot remember ever caring how a class got that way, just dealing with the way it is just now. –  Ozz Mar 20 '13 at 16:37
    
I do. Seeing the checkin comments on a bit of seemingly useless or WTFy legacy code is often useful in determining if it was added to handle a non-obvious edge case and needs to be kept (and the case added to the automated test suite) or can be removed/greatly simplified. This is especially useful for avoiding regression errors when the suspect code is breaking under a newly discovered edge case. –  Dan Neely Mar 20 '13 at 17:16
    
Maybe this is a function of how good the checkin comments I see are :-) –  Ozz Mar 20 '13 at 17:21
    
@DanNeely - sounds like the logic for marking out unused lines of code because they may be too difficult to trace in the source control system. Although I do realize the extra difficulty of multple files. –  JeffO Mar 20 '13 at 18:07
add comment

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.

share|improve this answer
    
I think you've misunderstood my question. I'm asking about if ClassfRefactoredFromOtherClass.cs should have it's history in source control trace back through OtherClass.cs or appear as a new file with only the checkin comment indicating that additional history can be found in OtherClass.cs –  Dan Neely Mar 21 '13 at 17:15
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.