mirror of
https://github.com/github/codeql.git
synced 2025-12-25 13:16:33 +01:00
63 lines
2.7 KiB
XML
63 lines
2.7 KiB
XML
<!DOCTYPE qhelp PUBLIC
|
|
"-//Semmle//qhelp//EN"
|
|
"qhelp.dtd">
|
|
<qhelp>
|
|
|
|
|
|
<overview>
|
|
<p>A method should never be duplicated exactly in several places in the code.
|
|
The severity of this problem is higher for longer methods than for extremely short
|
|
methods of one or two statements, but there are usually better ways of achieving the same
|
|
effect.</p>
|
|
|
|
<p>Code duplication in general is highly undesirable for a range of reasons. The artificially
|
|
inflated amount of code is more difficult to understand, and sequences of similar but subtly different lines
|
|
can mask the real purpose or intention behind them. Also, there is always a risk that only one
|
|
of several copies of the code is updated to address a defect or add a feature.</p>
|
|
|
|
</overview>
|
|
<recommendation>
|
|
|
|
<p>At its simplest, the duplication can be addressed by simply removing all but one of the duplicate
|
|
method definitions, and changing calls to the removed methods so that they call the remaining function
|
|
instead.</p>
|
|
|
|
<p>This may not be possible because of visibility or accessibility. A common example is
|
|
where two classes implement the same functionality but neither is a subtype of the other,
|
|
so it is not possible to inherit a single method definition. In such cases, introducing a
|
|
common superclass to share the duplicated code is a possible option. Alternatively, if the methods
|
|
do not need access to private object state, they can be moved to a shared utility class that
|
|
just provides the functionality itself.</p>
|
|
|
|
</recommendation>
|
|
<example>
|
|
|
|
<p>In the following example, <code>RowWidget</code> and <code>ColumnWidget</code> contain duplicate
|
|
methods. The <code>collectChildren</code> method should probably be moved into the
|
|
superclass, <code>Widget</code>, and shared between <code>RowWidget</code> and
|
|
<code>ColumnWidget</code>.</p>
|
|
|
|
<sample src="DuplicateMethod.java" />
|
|
|
|
<p>Alternatively, if not all kinds of <code>Widget</code> actually need <code>collectChildren</code>
|
|
(for example, not all of them have children), it might be necessary to introduce
|
|
a new, possibly abstract, class under <code>Widget</code>. For example, the new class might be called
|
|
<code>ContainerWidget</code> and include a single definition of <code>collectChildren</code>. Both
|
|
<code>RowWidget</code> and <code>ColumnWidget</code> could extend the class and inherit
|
|
<code>collectChildren</code>.</p>
|
|
|
|
<p>Modern IDEs may provide refactoring support for this sort of issue, usually
|
|
with the names "Pull up" or "Extract supertype".</p>
|
|
|
|
</example>
|
|
<references>
|
|
|
|
<li>E. Juergens, F. Deissenboeck, B. Hummel, S. Wagner.
|
|
<em>Do code clones matter?</em> Proceedings of the 31st International Conference on
|
|
Software Engineering,
|
|
485-495, 2009.</li>
|
|
|
|
|
|
</references>
|
|
</qhelp>
|