[debugging] killed a few mistakes

This commit is contained in:
Jan Grewe 2017-10-24 22:51:40 +02:00
parent 0292d8677f
commit 8f8166b528

View File

@ -172,9 +172,9 @@ expected elementwise multiplication.
\section{Logical error} \section{Logical error}
Sometimes a program runs smoothly and terminates without any Sometimes a program runs smoothly and terminates without any
error. This, however, does not necessarily mean that the program is complaint. This, however, does not necessarily mean that the program is
correct. We may have made a \codeterm{logical error}. Logical errors correct. We may have made a \codeterm{logical error}. Logical errors
are hard to find, \matlab{} has no chance to find this error and can are hard to find, \matlab{} has no chance to find such an error and can
not help us fixing bugs origination from these. We are on our own but not help us fixing bugs origination from these. We are on our own but
there are a few strategies that should help us. there are a few strategies that should help us.
@ -195,10 +195,10 @@ there are a few strategies that should help us.
\subsection{Avoiding errors --- Keep it small and simple} \subsection{Avoiding errors --- Keep it small and simple}
It would be great if we could just sit down write a program, run it It would be great if we could just sit down, write a program, run it,
and be done. Most likely this will not happen. Rather, we will make and be done with the task. Most likely this will not happen. Rather,
mistakes and have to bebug the code. There are a few guidelines that we will make mistakes and have to bebug the code. There are a few
help to reduce the number of errors. guidelines that help to reduce the number of errors.
\shortquote{Debugging time increases as a square of the program's \shortquote{Debugging time increases as a square of the program's
size.}{Chris Wenham} size.}{Chris Wenham}
@ -208,13 +208,13 @@ help to reduce the number of errors.
when you write it, how will you ever debug it?}{Brian Kernighan} when you write it, how will you ever debug it?}{Brian Kernighan}
Break down your programming problems into small parts (functions) that Break down your programming problems into small parts (functions) that
do exactly one thing. This has already been discussed in the context do exactly one thing and are thus easily testable. This has already
of writing scripts and functions. In parts this is just a matter of been discussed in the context of writing scripts and functions. In
feeling overwhelmed by 1000 lines of code. Further, with each task parts this is just a matter of feeling overwhelmed by 1000 lines of
that you incorporate into the same script the probability of naming code. Further, with each task that you incorporate into the same
conflicts (same or similar names for variables) increases. Remembering script the probability of naming conflicts (same or similar names for
the meaning of a certain variable that was defined in the beginning of variables) increases. Remembering the meaning of a certain variable
the script is just hard. that was defined in the beginning of the script is simply hard.
Many tasks within an analysis can be squashed into a single line of Many tasks within an analysis can be squashed into a single line of
code. This saves some space in the file, reduces the effort of coming code. This saves some space in the file, reduces the effort of coming
@ -244,7 +244,7 @@ about the programming skills of your target audience or other people
that may depend on your code? (iii) Is one solution faster or uses that may depend on your code? (iii) Is one solution faster or uses
less resources than the other? (iv) How much do you have to invest less resources than the other? (iv) How much do you have to invest
into the development of the most elegant solution relative to its into the development of the most elegant solution relative to its
importance in the project? The decision is up to you. importance in the project? The decision is yours.
\section{Debugging strategies} \section{Debugging strategies}
@ -254,10 +254,10 @@ solve the problem.
\begin{enumerate} \begin{enumerate}
\item Lean back and take a breath. \item Lean back and take a breath.
\item Read the error messages and identify the position in the code \item Read the error messages and identify the line or command where
where the error happens. Unfortunately this is not always the line the error happens. Unfortunately, the position that breaks is not
or command that really introduced the bug. In some instances the always the line or command that really introduced the bug. In some
actual error hides a few lines above. instances the actual error hides a few lines above.
\item No idea what the error message is trying to say? Google it! \item No idea what the error message is trying to say? Google it!
\item Read the program line by line and understand what each line is \item Read the program line by line and understand what each line is
doing. doing.
@ -268,11 +268,11 @@ solve the problem.
specific line and proceed step by step. Be sceptical and test all specific line and proceed step by step. Be sceptical and test all
steps for correctness. steps for correctness.
\item Call for help and explain the program to someone else. When you \item Call for help and explain the program to someone else. When you
do this start at the beginning and walk thorough the code line by do this, start at the beginning and walk through the program line by
line. Often it is not necessary that the other person is a line. Often it is not necessary that the other person is a
programmer or exactly understands what is going on. Often it is the programmer or exactly understands what is going on. Often, it is the
own refelction on the probelem and the chosen approach that helps own reflection on the problem and the chosen approach that helps
finding the bug. (This is strategy is also known as \codeterm{Rubber finding the bug. (This strategy is also known as \codeterm{Rubber
duck debugging}. duck debugging}.
\end{enumerate} \end{enumerate}
@ -280,24 +280,26 @@ solve the problem.
\subsection{Debugger} \subsection{Debugger}
The \matlab{} editor (figure\,\ref{editor_debugger}) supports The \matlab{} editor (figure\,\ref{editor_debugger}) supports
interactive debugging. Once you save a m-file in the editor and it interactive debugging. Once you save an m-file in the editor and it
passes the syntax check, i.e. the little box in the upper right corner passes the syntax check, i.e. the little box in the upper right corner
of the editor window is green or orange, you can set on or several of the editor window is green or orange, you can set one or several
\codeterm{break point}s. When the porgram is executed by calling it \codeterm{break point}s. When the program is executed by calling it
from the command line it will be stopped at the line with the from the command line it will be stopped at the line with the
breakpoint. In the editor this is indicated by a green arrow. The breakpoint. In the editor this is indicated by a green arrow. The
command line will change too to indicate that we are now stopped in command line will change to indicate that we are now stopped in
debug mode (listing\,\ref{debuggerlisting}). debug mode (listing\,\ref{debuggerlisting}).
\begin{figure} \begin{figure}
\centering \centering
\includegraphics[width=0.9\linewidth]{editor_debugger.png} \includegraphics[width=\linewidth]{editor_debugger.png}
\caption{Screenshot of the \matlab{} m-file editor. Once a file is \caption{Screenshot of the \matlab{} m-file editor. Once a file is
saved and passes the syntax check the green indicator (top-right saved and passes the syntax check (the indicator in the top-right
corner of the editor window), a breakpoint can be set. Breakpoints corner of the editor window turns green or orange), a breakpoint
can bes set either using the dropdown menu on top or by clicking can be set. Breakpoints can be set either using the dropdown menu
the line number on the left margin. An active breakpoint is on top or by clicking the line number on the left margin. An
indicated by a red dot.}\label{editor_debugger} active breakpoint is indicated by a red dot. The line at which the
program execution was stopped is indicated by the green
arrow.}\label{editor_debugger}
\end{figure} \end{figure}
@ -308,17 +310,17 @@ K>>
\end{lstlisting} \end{lstlisting}
When stopped in the debugger we can view and change the state of the When stopped in the debugger we can view and change the state of the
program at this step and try the next steps etc. Beware, however that program at this point, we can also issue commands to try the next
the state of a variable can be altered or even deleted which might steps etc. Beware however, the state of a variable can be altered or
affect the execution of the remaining code. even deleted which might affect the execution of the remaining code.
The toolbar of the editor offers now a new set of tools for debugging: The toolbar of the editor offers now a new set of tools for debugging:
\begin{enumerate} \begin{enumerate}
\item \textbf{Continue} --- simply move on until the program terminates or the \item \textbf{Continue} --- simply move on until the program terminates or the
execution reaches the next breakpoint. execution reaches the next breakpoint.
\item \textbf{Step} --- Execute the next command and stop. \item \textbf{Step} --- Execute the next command and stop.
\item \textbf{Step in} --- If the next command is the execution of a \item \textbf{Step in} --- If the next command is a
function step into it and stop at the first command. function call, step into it and stop at the first command.
\item \textbf{Step out} --- If the next command is a function call, \item \textbf{Step out} --- If the next command is a function call,
proceed until the called function returns, then stop. proceed until the called function returns, then stop.
\item \textbf{Run to cursor} --- Execute all statements up to the \item \textbf{Run to cursor} --- Execute all statements up to the
@ -328,7 +330,6 @@ The toolbar of the editor offers now a new set of tools for debugging:
\end{enumerate} \end{enumerate}
The debugger offers some more (advanced) features but the The debugger offers some more (advanced) features but the
functionality offered by the basic tools is often enough to debug the functionality offered by the basic tools is often enough to debug a program.
code.