If you’ve been writing code for any decent length of time, you will most likely come to the same conclusion I have.
If you’re new to writing code, I’m about to give you the single biggest secret to developing software.
The best code you will ever write is… code you never write.
No matter how good of a developer you are the simple truth of the matter is: any code you write will add complexity to your software system.
It’s true, any time you add functionality or logic to a system you make it more complicated. You may refactor some code and make the overall structure of the code more simple, but inevitably you will add complexity.
Salvation in a keystoke
It is not all gloom and doom from the developer looking to introduce simplicity to a code-base. There is one single key on the keyboard, which has done more for the cause of simplicity than any code that any developer has ever written: DELETE.
Good developers love to delete code.
The only thing I love to do more than write code is delete code. Deleting code brings me inner peace and joy. Deleting code is violating the law of entropy and setting the universe right.
Trust in source control
Often it is the case that developers are stricken by an unhealthy fear of deleting code. Perhaps it is a hold-over from the days when most software organizations didn’t use source control. Perhaps it comes from the pack-rat mentality of “what if I need this someday.”
Whatever the reason is, many developers are afraid to delete code.
If you’re one of those developers, I am here to set you free.
Repeat after me: “I trust my source control system to save the previous versions of any code I delete. I hereby solemnly swear to delete any commented out code. I promise to delete any code which is determined to the best of my knowledge as dead code.”
Don’t be afraid to delete code. If you have deemed that some code isn’t doing anything or it has no purpose hanging around, purge it. If you find that you need that code later, you can always pull it out of source control. Source control will remember that code exactly as you left it.
But it’s not hurting anyone
So why not just leave that dead code or commented code around? Why go out of your way to try to find ways to remove code and reduce code? There is no victim to this crime. No one gets hurt by having some dead code hanging around, or do they?
Every line of code in a software system has a maintenance cost associated with it, even dead commented out code, has to be maintained.
Don’t believe me? What happens when you have some commented out code that calls a method, and you change the name of the method? You have to, or rather you should, update the reference in the commented code. If you don’t, if you were to uncomment that code, it would no longer work.
So you can see that even commented code has a maintenance cost associated with it. The same can be said for dead code or copy and pasted excess code. The maintenance cost may be small, but it does exist and it adds up.
The other pain with dead code is the cost of comprehension. If you leave a method in a class that does nothing, every traveler coming through that class has to look at it, understand that is it not relevant and move on.
How many cars have to come down the road blocked by road construction and turn around, before you put up the “detour” sign?
Here are some tips which can help make you a “code hero” by doing the right thing, deleting that code.
- Look for commented out blocks of code. Almost every time I see a commented out block of code, I delete it. There is virtually no excuse someone can give me which will save the life of that poor abandoned code.
- Many IDEs and tools have the ability to detect unreachable code. Unless some kind of reflection magic is happening, unreachable code is dead code and is our enemy. Terminate it with much prejudice.
- Copy and pasted code blocks are dead code in disguise. The code is actually functioning, but it is still dead code. Find a way to consolidate the functionality into a single point that all the copy and pasted code can call, and delete the original code pointing it to the consolidated code.
- Tests that do nothing but get compiled are worthless. Get rid of them and don’t forget the “Ego Tests”, kill them or fix them.
- Look for old code that does things that libraries now do. If you find some implementation of a linked list, or a stack, or some other operation which exists in a base library, check and make sure there isn’t some really good reason it was implemented custom, and if there isn’t, take it out and replace it with a library call.