Removing duplicate code
Often the code in management style classes such as
ZipReplace
is quite generic
and can be applied in a variety of ways. It is possible to use either composition or
inheritance to help keep this code in one place, thus eliminating duplicate code.
Before we look at any examples of this, let's discuss a tiny bit of theory. Specifically,
why is duplicate code a bad thing?
www.it-ebooks.info
Chapter 5
[
141
]
There are several reasons, but they all boil down to readability and maintainability.
When we're writing a new piece of code that is similar to an earlier piece, the easiest
thing to do is copy the old code and change whatever needs to be changed (variable
names, logic, comments) to make it work in the new location. Alternatively, if we're
writing new code that seems similar, but not identical to code elsewhere in the project,
it is often easier to write fresh code with similar behavior, rather than figure out how
to extract the overlapping functionality.
But as soon as someone has to read and understand the code and they come across
duplicate blocks, they are faced with a dilemma. Code that might have made sense
suddenly has to be understood. How is one section different from the other? How
are they the same? Under what conditions is one section called? When do we call
the other? You might argue that you're the only one reading your code, but if you
don't touch that code for eight months it will be as incomprehensible to you as it is
to a fresh coder. When we're trying to read two similar pieces of code, we have to
understand why they're different, as well as how they're different. This wastes the
reader's time; code should always be written to be readable first.
I once had to try to understand someone's code that had three identical
copies of the same 300 lines of very poorly written code. I had been
working with the code for a month before I finally comprehended that
the three "identical" versions were actually performing slightly different
tax calculations. Some of the subtle differences were intentional, but
there were also obvious areas where someone had updated a calculation
in one function without updating the other two. The number of subtle,
incomprehensible bugs in the code could not be counted. I eventually
replaced all 900 lines with an easy-to-read function of 20 lines or so.
Reading such duplicate code can be tiresome, but code maintenance is even more
tormenting. As the preceding story suggests, keeping two similar pieces of code up
to date can be a nightmare. We have to remember to update both sections whenever
we update one of them, and we have to remember how the multiple sections differ so
we can modify our changes when we are editing each of them. If we forget to update
both sections, we will end up with extremely annoying bugs that usually manifest
themselves as, "but I fixed that already, why is it still happening?"
The result is that people who are reading or maintaining our code have to spend
astronomical amounts of time understanding and testing it compared to if we
had written the code in a nonrepetitive manner in the first place. It's even more
frustrating when we are the ones doing the maintenance; we find ourselves saying,
"why didn't I do this right the first time?" The time we save by copy-pasting existing
code is lost the very first time we have to maintain it. Code is both read and modified
many more times and much more often than it is written. Comprehensible code
should always be paramount.
www.it-ebooks.info
When to Use Object-oriented Programming
Do'stlaringiz bilan baham: |