Kill the Zombie code in your program.

As Halloween gets more popular, we want to talk about a very common problem in software development: Zombie code. Almost all of the code libraries that have been exposed are scattered with small chunks of code, or even large chunks of it being commented out. This is the zombie code.

This feature is currently disabled. Jimmy must have been drunk when he wrote this piece of code.

You might think there's a scary code killer case ... No, no, I just commented them out ...

Why call them zombie code? You know, zombies don't really die. As I'm afraid the movie tells us, although zombies look dead, they still have the ability to attack us. In the same way, zombie code is also in the midst of life and death ... They're waiting to mess up our jobs. The annotated code is still alive, and they exist in our code base. Programmers encounter them when they maintain and refactor code, usually when scrolling through the screen, or when they hit a keyword search. But the code is also dead, because they are not implemented in software products. So, these zombies should be burnt down, right away.

Zombie Code Undead

I think there are two reasons why zombie code is rampant: laziness and fear of risk. Lazy programmers have a fetish for code. They lack certainty of courage and a clear understanding to remove useless code, so they hide them in the comments, hoping that they will one day be resurrected to scourge again. Code requires frequent, planned deletions, because good programmers know that code is debt. The less the better. Of course, the commented out code is still code.

Bad programmers might argue that they commented out the code to "in case" someone else would need them. In fact, this kind of kindness has harmed everyone. This is actually about fear of risk and lack of trust in the role of version control systems. There is a version control system in which the deleted code will never really die. They're buried in coffins, but they're alive. Therefore, the method of annotating code has little practical utility.

For a program, the annotated code is no more useful than the deleted code. Keep your code alive, zombie-style, and create technical debt that will ultimately hurt your team. Be resolute and delete them.

Zombie Code lowers signal-to-noise ratio

When writing a program, we must try to make the ratio of valid information in the code higher the better. This helps people understand the program, read the code faster, and prevent us from writing problematic code because of misunderstanding. The zombie code is directly adversarial to the understanding of the code. It slows us down in reading and maintaining code because it allows us to see fewer valid code on the screen. They are visual noises that interfere with people's normal reading. For some reason, some programmers will accept this compromise, but in reality, who will accept this messy picture. Imagine if the New York Times looks like this:

How do you read this staccato text? The increase in noise is an impairment of understanding. You can't turn a blind eye to these annotated parts, even if they are irrelevant or misleading. Some would say that this is not the final release of the product, the code exists in the development process, to compare them with the published products, which is like taking apples than oranges. But keep in mind that every line of code written is read on average 10 times. Yes, your code reads no more than the New York Times, but what you have is one of the most important and loyal reading groups. Is us. Knuth has made a penetrating summary of this concern:

"Programming is the art of a person telling another person what he wants the computer to do." "Donald Knuth

And the zombie code makes you not speak clearly. Does a programmer need to read the commented out code?

The zombie code causes ambiguity to interfere with debugging

The annotated code is ambiguous and people wonder if the code should be commented out. Imagine that you are a programmer to maintain a program, and suddenly you see a commented out code, and the program is in the vicinity of the problem. The programmer's task will become more difficult. He needs to read and understand these annotated codes to see how they are affected. Did you annotate the code for the test but forgot to restore it? Maybe the people who annotate the code can help, but who is he? The investigation action begins. Extra ambiguity can consume your time and increase your thinking burden-it could have been an easy debugging process.

Zombie Code Impact Keyword Search

In a large library, the Grep/find command will be your radar that locks up certain pieces of code. However, if the library is littered with zombie code, it's likely that the target you're capturing is commented out. This is interference. Waste of time.

Zombie Code Impact Code Refactoring

Reflection (reconstruction) can repair our soul. We should be proud of the child's Scout principles, and always keep the code clean and tidy than you think. However, when a class or method contains a large number of zombie code, things are difficult to deal with. If you refactor this program, do I also refer to the annotated code? Will they be reused in the near future? Does it affect my new version of the implementation? These questions should not be answered for the maintenance programmer.

In addition, the integrated refactoring tool does not consider these annotated code at all. Therefore, when methods, variables, and classes are renamed or modifiers are changed, the annotated code is not synchronized for modification. When you re trying to revive annotated code, they are probably not compiled at all.

Any exceptions?

No. Very clear. Someone would say, "I'm annotating them now because I'm going to recover them later." "OK, suppose you're a family woman, you walk into the living room and see:

Think of your inner dialogue. It's a beautiful house, but it's ugly and weird. I want to turn on the light, but how can I have duct tape? What happens if I rip off the tape to turn on the light? You'll probably finally decide to find someone to tape. "Oh, I want to turn on the ceiling fan, but it starts swinging back and forth, falling down, and I want to fix it ..." Of course, it should be. And before you fix it, the tape is stuck on the switch. Of course, we shouldn't let these only half of the things exist in the house. Similarly, we do not accept such code.

To be more clear, any annotated code is a zombie code, should be deleted. No matter how many. Whether it's in a published product or in a development environment. Zombie code sometimes swings between life and death. If the code is commented out, there is a good chance that something is not done. Often the configuration needs to be switched back and forth or the logical branches sway around. The annotation code might do an experimental back and forth, delete the code, build a post-it note, and record what needs to be done. Delete this code when you make a note of which version was submitted in the memo post. Alternatively, create a new version of the branch that specializes in doing this and deletes them when merging. In this way, maintenance work will not be disturbed.

A checklist of My heart

If you are going to annotate a piece of code, ask yourself first:

• When possible, when will the annotation be canceled?
• Is it possible to delete it and retrieve it from the version control system if necessary in the future?
• Can you handle these unfinished, possibly rolled back code with a version branch?
• Can this feature be configured to switch annotations back and forth?
• Do refactoring also need to refactor these commented out code?

Let's start the first annual Halloween zombie code big sweep.