DEV Community

Cover image for Dead code - alive problem
Damnjan Jovanovic
Damnjan Jovanovic

Posted on

Dead code - alive problem

How many times I saw commented part of the code, or I did comment it myself, to stay there as some kind of reminder that I have to apply action afterward. How many times I saw dead code from other developers commented or uncommented laying around and pretend it has a purpose. Well, I saw that quite enough that I already know all the answers why this particular dead code is there.

Usually, dead code is left behind because of several reasons:

  • Dead code as a reminder
  • Dead code for testing things
  • Dead code looking into future
  • Artistic dead code

Dead code reminder

This should be a reminder that we have to perform some action once when the right time comes. Some amount of work is already done, but we can’t do more refactoring at the moment to apply this change, or we don’t have time for additional code necessary to implement this change now. This is very common if the developer got an idea during working on some unrelated issue and can’t switch focus at the moment, but can leave guidelines for some future self when he has more time.

How to deal with it
If you are not the creator of this piece of software which is commented out, try to get in touch with creator and figure out does it make sense to remove it or finally implement.

Register ticket in your ticketing system which reminds you that you have to implement this change. Try to uncomment this code and put it in a separate module, or isolate as a different function. Put TODO or FIXME reminder to that code which will indicate to any developer who comes across that this pease of code, that it has to be implemented.

Conclusion: If all steps from “solution” part sound way too complicated, then it might not worth keeping it, just delete dead code.

Dead code testing things

Dead and commented code could be an “old” way how the application worked, so we just trying out a (testing) different approach with new code until we are sure which one we want to keep. In this case, dead code is A case in AB testing. I see this example, many times when the strange bug appears, or developer try out a new approach to the problem, maybe optimizing part of the code or using a different library. But still, he left the unused piece of code

How to deal with it
Hopefully, you got the data and conclusion which part of the code works better for you, so you don’t need to keep them both.

If necessary, test things once again, hopefully, you have unit tests which can prove that both solutions (commented one and uncommented) work. If you don’t have any unit test there create it, it will be the only way that you can adequately judge which code to keep.

Conclusion: There is no case when you need to keep A and B solution after you try out AB testing. Get rid of other solution as soon as possible.

Dead code looking into future

Dead code which laying there and waiting for its chance to be used. Premature optimizing, thinking way too much in advance about future requests.

How to deal with it
The code should be removed, no matter what emotional connection it has with the developer, regarding the amount of work and mental effort invested. Keeping this code in the code base is very poisoning, it introduces confusion for newcomers, and most probably this feature will never be used.

Implement thing as they are requested. It is very helpful to keep your code extendable, but predicting too much in advance which feature might be needed or change has to be implemented could be painful.

Conclusion: Follow 5 SOLID principles, and you’ll be just fine with maintaining extensions of your code.

Dead code as a state of the art

Nobody can’t tell for sure why this code is still there, but everybody avoids to do so, in respect to the effort used for writing this piece of software.

How to deal with it
Delete it and commit, then push to master.

Seriously, delete it.

Conclusion: Nobody needs someone temporary thoughts in production

Top comments (6)

gzg profile image
Ekin Öcalan

Uncle Bob agrees. :-) Quoting the book Clean Code:

It makes me crazy to see stretches of code that are commented out. [...] That code sits there and rots, getting less and less relevant with every passing day. It calls functions that no longer exist. It uses variables whose names have changed. It follows conventions that are long obsolete. It pollutes the modules that contain it and distracts the people who try to read it. Commented-out code is an abomination.

Just use any version control system and then delete the code.

arturoaviles profile image
Arturo Avilés

Great article Damnjan! I wonder if with all the changes that a project can have, if big companies ask software engineers, who are not related to the project, to read the code and keep the comments updated or, at least, send tickets saying that the comments are outdated.

What you think?

I think it's sometimes easier to ask the engineer that created the code to reread it, but I also think that such thing may be biased.

I'm also interested in knowing other people opinions in this subject.

jessekphillips profile image
Jesse Phillips

Delete it. You are in git right? Delete. If it isn't in history a branch might be OK.

sandordargo profile image
Sandor Dargo

You're right. Kill 'em all. If someone really wants them, git doesn't forget.

sanidz profile image
sanidz • Edited

Introduce CR and delete the crap before it hits repo and make everyone apply boyscout rule.

burdettelamar profile image
Burdette Lamar

Another thing: Be a good citizen.

If you ever comment out code, add another comment:

  • Why commented out.
  • Why not deleted.
  • Occasion for commenting back in.