% chapter-01.tex

\chapter{Introduction}
For many programmers, copying and pasting code is unavoidable. It is therefore
surprising that existing programming editors provide little support for copy and
paste beyond ordinary text editing and refactoring. For example, Eclipse performs
automatic refactoring when a programmer copies and pastes a class. Refactoring
alone, however, is not enough.

Each copy-and-paste action carries information that can help programmers
understand and maintain related code. Kim~\cite{ethnography} observes, ``In fact
programmers employ their memory of C\&P history as they make changes to code or
decide when to restructure code.'' She continues, ``However, a programmer's
recollection of C\&P history can be short-lived, somewhat inaccurate, and
difficult to transfer from person to person.''

Copy-and-paste operations therefore play an important role in software
development. To provide better support for developers, we must analyze those
operations more carefully. In particular, we need to understand what information
is lost when the IDE does not track copy-and-paste history.

\section{Problem: Loss of Relationship}

Developers often copy and paste code within a class, or copy an entire class,
because there is meaningful similarity between the source and the target. That
similarity is evident to the developer at the time of the copy-and-paste
operation, but it may not be evident to another developer, or even to the same
developer at a later time.

In other words, copied and pasted code contains an implicit relationship. If the
IDE does not track the copy-and-paste operation, that relationship is lost. Even
when the relationship is known, developers still need detailed information about
how the clones differ.

\section{Problem: Missing Detailed Information}

Detailed information includes how clones differ, where new statements were
inserted, and which statements were deleted, moved, or updated. This
fine-grained information can:
\begin{enumerate}
\item{Improve understanding between related clones}
\item{Guide similar copy-and-paste operations in the future}
\end{enumerate}

These differences can support a better understanding of the code. The problem is
more difficult when clones are located in different files, because the developer
must leave the editor context and use a separate tool, such as the Eclipse
Compare Editor, or manually compare the files. The limitations of the Compare
Editor are discussed in the validation chapter.

\section{Example Scenario}
\begin{figure}
\centering
\resizebox{\textwidth}{!}{
\includegraphics{../images/setfilterwizardexclusiondialog.png}}
\caption{SetFilterWizardPage and ExclusionInclusionDialog}
\label{setfilterdialogfig}
\end{figure}

Consider Figure \ref{setfilterdialogfig}. SetFilterWizardPage is a wizard page
used when creating a new source folder to include or exclude file patterns from
the build path. A brief study of this class's history suggests that it was
previously implemented as a dialog and later replaced by a wizard page. The
earlier dialog was not deleted; it was maintained so that external clients could
set file patterns in a source folder independently of creating or editing the
source folder. Most likely, the new SetFilterWizardPage class was copied from
ExclusionInclusionDialog.

\paragraph{Problem: Loss of Relationship}
Consider a situation in which a developer modifies SetFilterWizardPage. The same
change may also be required in ExclusionInclusionDialog. For example, a change
for BIDI (bidirectional support for internationalization) was added to
SetFilterWizardPage and then added to ExclusionInclusionDialog as well. A similar
case occurred for a bug fix related to new source-folder creation.

The question is how a programmer can know which classes are affected by a bug fix
or change. What relationship do these classes have? Even if the Eclipse team
decides to remove the duplicates, they still need to know which classes were
created in a similar fashion and how similar those classes are.

\paragraph{Problem: Loss of Detailed Information}
\begin{figure}
\centering
\includegraphics{../images/outlinemarked.png}
\caption{Outline View of SetFilterWizardPage and ExclusionInclusionDialog}
\label{outlinefig}
\end{figure}
Even when the relationship is known, finding detailed differences between clones
can be time-consuming. In the example scenario, part of the outline view of the
two classes is shown in Figure \ref{outlinefig}. A developer may want to know
which methods in SetFilterWizardPage were removed, which methods correspond to
methods in ExclusionInclusionDialog, and which methods are new in
ExclusionInclusionDialog. These questions are not limited to methods; they can
also apply at the expression level.

\section{Tracking and Visualizing Detailed Code Differences}
CSeR addresses these problems by calculating changes with an incremental
AST-based algorithm. The changes are shown directly in the editor and are
calculated as the user edits the code. For the example considered here, once
ExclusionInclusionDialog is created in an environment that supports CSeR, the
code appears as shown in Figure \ref{setfilterfig1}.

\begin{figure}[h]
\centering
\resizebox{\textwidth}{!}{
\includegraphics{../images/setfilter2.png}}
\caption{CSeR Showing SetFilterWizardPage from ExclusionInclusionDialog}
\label{setfilterfig1}
\end{figure}

The remainder of this thesis is organized as follows. Chapter 2 introduces the
basic definitions and background information. Chapter 3 explains the design of
CSeR in detail. Chapter 4 validates the tool. Chapters 5 and 6 discuss related
work and present the conclusion and future work.
