\begin{quote}
Software entities (classes, modules, functions, etc.) should be open for
- extension, but closed for modification.\footnote{See
- \url{http://c2.com/cgi/wiki?OpenClosedPrinciple} or
- \url{https://en.wikipedia.org/wiki/Open/closed_principle}}
+ extension, but closed for modification.
\end{quote}
Maintainability is often thought of as the ability to be able to introduce new
\end{listing}
The bug introduced in the previous example is of such a nature\footnote{Caused
- by aliasing. See \url{https://en.wikipedia.org/wiki/Aliasing_(computing)}}
- that it is very difficult to spot if the refactored code is not covered by
- tests. It does not generate compilation errors, and will thus only result in
- a runtime error or corrupted data, which might be hard to detect.
+by aliasing.} that it is very difficult to spot if the refactored code is not
+covered by tests. It does not generate compilation errors, and will thus only
+result in a runtime error or corrupted data, which might be hard to detect.
\subsection{Refactoring and the importance of testing}\label{testing}
\begin{quote}
\section{Related work}\label{sec:relatedWork}
Here we present some work related to automated composition of refactorings.
-\subsection{Refactoring safety}
+\subsection{Refactoring safety}\label{sec:saferRefactoring}
This section presents a couple of approaches to improving the safety of
performing refactorings. In these approaches, the problems that are addressed
are not compilation problems, but behavior-altering problems that are not easily
performs an analysis of the structure of a program. It verifies that the syntax
is correct according to the grammar rules of a language, that are usually
specified in a context-free grammar, and often in a variant of the
-\name{Backus--Naur
-Form}\footnote{\url{https://en.wikipedia.org/wiki/Backus-Naur\_Form}}. The
-result coming from the parser is in the form of an \emph{Abstract Syntax Tree},
-AST for short. It is called \emph{abstract}, because the structure does not
-contain all of the tokens produced by the scanner. It only contains logical
-constructs, and because it forms a tree, all kinds of parentheses and brackets
-are implicit in the structure. It is this AST that is used when performing the
-semantic analysis of the code.
+\name{Backus--Naur Form}. The result coming from the parser is in the form of an
+\emph{Abstract Syntax Tree}, AST for short. It is called \emph{abstract},
+because the structure does not contain all of the tokens produced by the
+scanner. It only contains logical constructs, and because it forms a tree, all
+kinds of parentheses and brackets are implicit in the structure. It is this AST
+that is used when performing the semantic analysis of the code.
As an example we can think of the expression \code{(5 + 7) * 2}. The root of
this tree would in \name{Eclipse} be an \type{InfixExpression} with the operator
\caption{The format of the abstract syntax tree in \name{Eclipse}.}
\label{fig:astEclipse}
\end{figure}
-\todoin{Add more to the AST format tree? \myref{fig:astEclipse}}
\section{The ASTVisitor}\label{astVisitor}
So far, the only thing that has been addressed is how the data that is going to
finds unfixes within a selection.
\todoin{Give more technical detail?}
-
-
-\subsection{The ContainsReturnStatementCollector}
-\todoin{Remove section?}
-The
-\typewithref{no.uio.ifi.refaktor.analyze.collectors}{ContainsReturnStatementCollector}
-is a very simple property collector. It only visits the return statements within
-a selection, and can report whether it encountered a return statement or not.
-
-\subsection{The LastStatementCollector}
-The \typewithref{no.uio.ifi.refaktor.analyze.collectors}{LastStatementCollector}
-collects the last statement of a selection. It does so by only visiting the top
-level statements of the selection, and compares the textual end offset of each
-encountered statement with the end offset of the previous statement found.
-
\section{Checkers}\label{checkers}
The checkers are a range of classes that checks that text selections comply
with certain criteria. All checkers operates under the assumption that the code
review them and choose whether or not they should be performed.
\section{Future work}
-\todoin{Find out if a complete analysis is feasible}
-\todoin{Complete the analysis}
-\todoin{Make refactorings safer (behavior)}
-\todoin{Improve heuristics/introduce metrics}
+An important part that is missing for making the search-based
+\ExtractAndMoveMethod refactoring more usable, is to complete the
+pre-refactoring analysis of the source code, to make sure that the refactoring
+does not introduce compilation errors when it is performed.
+
+The first point of making the static analysis complete brings up the next
+question: Is it feasible to complete such an analysis? Can this feasibility be
+proven, or disproved?
+
+Another shortcoming of this project is that we have no strategy for assuring
+safety when refactoring, so the code may end up behaving differently after the
+refactoring than it behaved before. Approaches toward safer refactorings are
+mentioned in \myref{sec:saferRefactoring}.
+
+The last important improvement that could be made to this project is to refine
+the heuristics that is used to find suitable refactoring candidates. This effort
+should in particular be directed toward making the heuristics choose candidates
+that do not introduce new dependencies for their destination classes.
\appendix