Comments on: Coding: Unused code

By: Tiendq

Tiendq — Wed, 26 Aug 2009 08:37:42 +0000

Of course, don't forget to leave a meaningful comment at where code is removed.

By: Tiendq

Tiendq — Wed, 26 Aug 2009 08:35:02 +0000

We have been refactoring our code base of last project and face this issue too. Unused and long comment out code make me sick during code review. It cost me lots of time to find out if a specific method is used or not, code coverage is very useful in this situation but it isn't always right in all cases. I think the quickest and most efficient approach for this issue is removing it completely. If developers need it later, just come to code repository.

By: Mark Needham

Mark Needham — Fri, 21 Aug 2009 12:13:07 +0000

Interesting ideas, I guess perhaps the option of branching/tagging the feature and then removing it is probably a reasonable approach.

Strangely enough straight after I posted this I was working on some code with a colleague and a feature we originally implemented 6 months ago but which was then deemed unnecessay was rewritten in an ever so slightly different way cause we had different people working on it the second time than the first and we didn't pick up on the fact it was already done a different way!

Quite frustrating because the old code is now getting in the way and has increased the complexity of what we're doing.

By: ilivewithian

ilivewithian — Fri, 21 Aug 2009 11:27:33 +0000

I'm with Jeremy, branch the code. Even if you've ended up with the code in the main trunk branch it, then delete it from the trunk.

I try to keep the main trunk as clean as possible, that way moving towards continuous deployment becomes more realistic.

By: Vijay Aravamudhan

Vijay Aravamudhan — Fri, 21 Aug 2009 11:10:50 +0000

One other (hard-line) approach is to simply nuke the code. If it is sufficiently soon AND important that it needs to be resurrected, someone on the team would remember that this code was checked in (and could later find it with the commit history logs – assuming that you checked it in at least once). This approach also allows the [possibly] new pair to implement it in a different manner (debatable whether the new one is actually better or not) – but hopefully with more knowledge of the changed business process/requirement.

By: Frank Carver

Frank Carver — Fri, 21 Aug 2009 09:25:00 +0000

The idea of removing the code from the current version, and leaving the footprints in the source control system is appealing, but it does have its probblems.

Having taken this approach without regrets several times, I eventually found myself actually needing to look up some old unused and deleted code.

Unfortunately it was very hard to find. Most SCM systems I have used treat the file as the key repository item, and make access to the history of deleted files quite tricky. This is just about doable if you can remember the name of the file in question, but this is not often true in a highly fluid, mercilessly-refactoring code base.

Finding the various bits which comprised the deleted feature turned into quite a forensic exercise.

My recommendation is that you should *always* meaningfully tag or branch the repository state before performing such a deletion. This few seconds of effort can save hours of frustration if you do ever need to look back.

By: Willem van den Ende

Willem van den Ende — Fri, 21 Aug 2009 08:30:04 +0000

I'm with Mark Dalgarno on this. Remove it, and you _could_ refer to it later.
In practice referring back to it rarely happens – as you say, the business idea of the abandoned feature has evolved in the meantime, so it is much faster to write new tests with fresh code.
I recommend throwing away code often. If there is one thing I should (still) be doing more is throwing away code e.g. keeping code after a spike and then moulding it into production ready code takes much longer than throwing the spike away and working again from tests, but still I can't help myself sometimes…

By: Mark Dalgarno

Mark Dalgarno — Fri, 21 Aug 2009 07:43:28 +0000

The approach of removing it from the code base feels much cleaner and more satisfying to me.

If you do need the feature at a later date you should still have the knowledge of how it had been partially implemented and you should be able to refer back to your source control system to see what actually had been done complement this knowledge.

By: Reflective Perspective - Chris Alcock » The Morning Brew #417

Reflective Perspective - Chris Alcock » The Morning Brew #417 — Fri, 21 Aug 2009 07:31:51 +0000

[...] Coding: Unused code – Mark Needham talks about the dilemma of what to do with code that is no longer needed, be it replaced or an abandoned partially implemented feature. [...]

By: Jeremy Gray

Jeremy Gray — Fri, 21 Aug 2009 04:42:26 +0000

Cut that code into a branch, nuke it in your main line of development (or cut a new main line of development, or whichever of a number of rough equivalents that best suit your chosen branching model), and then move on. If you do want to look back on it or even dredge it back up as it was, you'll have that branch there.