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.

Solution
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.

Solution
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.

Solution
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.

Solution
Seriously, delete it.

Conclusion: Nobody needs someone temporary thoughts in production