Dead code - alive problem
Tags: git, programming, webdev, productivity
Published: 2019-04-26 13:49:13

---
cover_image: https://media.giphy.com/media/14iKjh4NGOCinS/giphy.gif
title: Dead code - alive problem
published: true
description: How to deal with commented code
tags: git, programming, webdev, productivity
---

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