Redundant code, defined for this purpose as code that’s not innately adding to your software is one of the threats to the future maintenance and operation of the software. My view is that you should eliminate any redundancy you find to get the code into its simplest form. The hard part is usually finding the redundancy, rather than removing it, which in a tested codebase is generally straightforward, or at least worthwhile.
Here are three redundancies I can think of:
- Over written
- Hard work
Over written software
This stuff makes no difference at runtime, but it’s longer to read. The long-winded approach gives the code maintainer screens full of stuff that could be expressed with less duplication, or with fewer words. The compiler probably gets rid of most of the cruft, leaving an efficient runtime, but boy is it cumbersome to wade through a Peter and Jane short story when visiting some functions.
In this instance, you have code which is long-winded for the computer. Perhaps it lacks temp variables to hold the return of a function, so the function is being called repeatedly. Perhaps there’s the wrong sort of collection used, so the algorithmic complexity is higher than it needs to be. Perhaps there’s been an optimisation for readability that hits the CPU hard, or just a lack of thought about how to make something worth paying for powering a CPU to do.
Sometimes an algorithm isn’t there to make the computer do something. Sometimes the technique is there to allow the developer to show off their kool skillz. As such, this sort of intellectual posturing can’t end well. The aim of code is to express the intent, not show off an unusual ninja trick.
If there’s a commonplace simple way of doing something, a show-off version, unless it’s solving a second-degree problem, is simply a design bug.
You may know other wastes of our coding and reading time – I’d be interested to hear about them.