Zombie Code
–
“Zombie code is an expression used to describe software functionality that is more or less abandoned or unsupported but which still appears in the current source code,” explains Daniel Stubbs, scientific analyst at Calcul Quebec and part of the Compute Canada Federation.
These lines of code are no longer useful and they are not executed. They should no longer be there but for reasons that are often obscure, they are still clearly visible, rendering the program’s source code needlessly mysterious, sometimes to the point of being outright unreadable!
Fortunately, zombie code is not as dangerous as the brain-eating zombies found in horror movies (and honestly, our analysis team much prefers to deal with the former). Zombie code is nevertheless a nuisance and when it becomes ubiquitous, it can give your code a post-apocalyptic look…
“Zombie code is unfortunately fairly common,” says Daniel Stubbs. “For example, we help many researchers who are not experts in programming: they are first and foremost experts in their scientific domain. As a result, we meet a lot of zombies.”
“Poorly written code is confusing, which makes it more difficult to update, extend or optimize. Overall, it’s harder for us to help the individual. Such code can also lead to very subtle bugs that require a lot of effort to eliminate,” he adds. Zombie code can also be brought back to life by mistake, potentially causing a multitude of problems! Zombie-infested code can also waste memory, CPU cycles and increase execution time.
How to eliminate them?
Since zombies are already dead, it’s not easy to kill them. And just like in the movies…not all zombies are the same. Some are easy to identify and kill, while others are a nightmare!
There is no miracle solution, except perhaps, to avoid creating them in the first place. Many zombies are created at the very beginning of writing a program, as the author of the code, out of a fear of deleting code which may later prove useful or being forced to start over, prefers to retain multiple versions in a single file by using comments and changing the name of functions and variables.
“If your code is chaotic and you have trouble understanding it yourself, imagine sharing it with someone who didn’t write it. Your goal should be to write code that you’ll be proud to share with others,” adds our analyst.
Advice from a scientific analyst
It’s easy to write code, but it takes a little more time and energy to write good code – but in the long run, it is worth it!
– Use good software engineering practices.
– Remove old and deprecated code (“cruft”) from your source code files.
– Document your code.
– Use good version management software: this will allow you to keep your code readable while still having access to earlier versions. At Calcul Québec we offer a workshop with GIT
Zombie hunting !
Our analyste prepared an exemple of a (very bad) code in C, but that can still compile and execute. He also made a much nicer version.
–
About this article
This article was written in collaboration and revised by a high performance computing expert.
Daniel Stubbs studied mathematics at the University of Toronto and Western University, where he received his PHD in 2000. He then worked as a scientific programmer in a pharmaceutical company before becoming a scientific analyst at McMaster University (SHARCNet) and, from 2005, at the University of Montreal (Calcul Québec). For several years now, he has been one of Calcul Québec’s analysts in charge of user support.
