9

So I was reading over this question Should I remove unreferenced code?

Some of the advice was to delete unreferenced code since the code is in source control for reference in case it is needed later.

How do you organize this deleted code so that a later version of you (or some other programmer) can find it later? Do you make a separate branch or tag it in source control somehow?

I have never resurrected deleted code out of source control before, I've mostly just used it to track changes on code that is still live. I have referenced branches before when they have contained someone else's experimental work, so maybe that's a good way to mark interesting sections of code that is deleted in trunk?

Community
  • 1
Peter Smith
  • 2,587
  • 19
  • 21
  • what vcs are you asking avout? sounds like [tag:svn] – gnat Mar 14 '16 at 17:40
  • svn is what I have in mind, but could apply to any source control, I think? – Peter Smith Mar 14 '16 at 18:18
  • You say: "What I have more in mind are cancelled or postponed projects" in a reaction to an answer. I think you should edit your question because that is quite different from "unreferenced code". – Pieter B Mar 15 '16 at 09:50

4 Answers4

6

Unless you're experimenting in a branch and aren't yet sure which solution will ultimately be reintegrated, you usually don't refer to deleted code.

You might, on very rare occasion, explicitly dig for removed code that you vaguely recall solving a problem you have right now. But, the more typical reason you'll see deleted code is when you're looking through the backlog to understand something about an application's current code or behavior with respect to its historical code or behavior.

Specifically, you might be ...

  • doing a general code review / understanding a refactor
  • looking for the commit that introduced bug X
  • satisfying your curiosity / looking for the commit that solved a bug
  • re-implementing a feature or similar feature
  • understanding code or data that seems like it works in conjunction with code that doesn't exist

... etc.

And in those cases, you're not typically resurrecting old code. You're just understanding something you see right now using removed code for context or guidance.

svidgen
  • 13,414
  • 2
  • 34
  • 60
4

I guess, the answer is: The vast majority of programmers doesn't care to reference deleted code. For several reasons. Some reasons that come to my mind are:

  • Probably most importantly, pure laziness...

  • Most never felt the need to resurrect some code, so they don't have any experience that motivates them to make resurrecting code easier.

  • Most code that's deleted is deleted for a reason. Usually, it's replaced by some other, better, functionally equivalent or more powerful code. Why would anyone want to resurrect the inferior code?

    Note that this is also a psychological issue again: Most programmers are quite proud of the results of their work. How could it ever come to mind that there was still some value in what they replaced?

  • Since most code is not purely deleted, but replaced, the interfaces that have been changed in the transition provide enough information if you really need to track down the deleted code due to some regressions introduced by the new code.

But, independent of how much more or less valid reasons you can put behind this disregard for dead code, I think it's really just a "don't care" on the part of the programmers. And even if you try to mark deleted stuff in some or the other way, be prepared to be thoroughly ignored with that effort...

cmaster - reinstate monica
  • 7,941
  • 1
  • 22
  • 25
  • I guess I'll try to answer why. If it's replaced code, it makes sense after a short period of time, the deleted code is no longer really necessary. What I have more in mind are cancelled or postponed projects. Particularly those where some large amount of functionality was developed or changed, but ultimately not fully completed and not used in current production. – Peter Smith Mar 14 '16 at 18:21
  • 1
    @PeterSmith: You should create separate branches for such code. Then there is no need to delete the code, since it does not exist in the working branch anyway. – JacquesB Mar 14 '16 at 19:07
  • Adding to what @JacquesB said, if you have any code that is not used at all, it tends to get outdated rather quickly. You may be able to revive a dead branch after a year, after five years you'll have to restart from scratch. The dead branch may still come in useful as a source of ideas, but it's code itself is likely not to be usable anymore. – cmaster - reinstate monica Mar 14 '16 at 20:15
1

This question probably falls back on "How do you keep tracability of your VCS checkins against the bug database and your system requirements?"

The times when people go to resurrect code from Source control tend to be those times when you find out that something got unintentionally broken and needs to be brought back.

The most important thing in that scenario for someone looking for a specific bit of removed code is that they can easily trace it by looking through the requirements database and the bug tracking tool; because they are likely to be searching for the specific requirement, or words which describe the functionality. They are unlikely to know the name of the source file or the class/function which was removed.

If you want to track some interesting/experimental code which needs to be taken out before release, you could simply trace it with some "bug" tickets along the lines of "Remove unused code for ...". Or maybe introduce a new type of ticket to the system for Prototype feature.

So to answer the question directly - don't use branches/tags in your VCS system to track deleted code - use your change tracking tool.

Ben Cottrell
  • 11,656
  • 4
  • 30
  • 41
0

The advice is intended for people who keep obsolete code in the codebase "just in case". Since the code will still exist in source control, you should not fear deleting it. You don't really organize deleted code as such, since the whole point is that it it not needed anymore. You just add commit message which indicate what was changed and deleted in the commit. The most relevant commit message for the deleted code is the message at the time the code was initially added, not the message when it was deleted again.

"Experimental work" is really a different issue. You should have a separate branch for that.

JacquesB
  • 57,310
  • 21
  • 127
  • 176