[debugging] killed a few mistakes

debugging/lecture/debugging.tex

@@ -172,9 +172,9 @@ expected elementwise multiplication.
 
 \section{Logical error}
 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
-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
 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}
 
-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
-mistakes and have to bebug the code. There are a few guidelines that
-help to reduce the number of errors.
+It would be great if we could just sit down, write a program, run it,
+and be done with the task. Most likely this will not happen. Rather,
+we will make mistakes and have to bebug the code. There are a few
+guidelines that help to reduce the number of errors.
 
 \shortquote{Debugging time increases as a square of the program's
   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}
 
 Break down your programming problems into small parts (functions) that
-do exactly one thing. This has already been discussed in the context
-of writing scripts and functions. In parts this is just a matter of
-feeling overwhelmed by 1000 lines of code. Further, with each task
-that you incorporate into the same script the probability of naming
-conflicts (same or similar names for variables) increases. Remembering
-the meaning of a certain variable that was defined in the beginning of
-the script is just hard.
+do exactly one thing and are thus easily testable. This has already
+been discussed in the context of writing scripts and functions. In
+parts this is just a matter of feeling overwhelmed by 1000 lines of
+code. Further, with each task that you incorporate into the same
+script the probability of naming conflicts (same or similar names for
+variables) increases. Remembering the meaning of a certain variable
+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
 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
 less resources than the other? (iv) How much do you have to invest
 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}
@@ -254,10 +254,10 @@ solve the problem.
 
 \begin{enumerate}
 \item Lean back and take a breath.
-\item Read the error messages and identify the position in the code
-  where the error happens. Unfortunately this is not always the line
-  or command that really introduced the bug. In some instances the
-  actual error hides a few lines above.
+\item Read the error messages and identify the line or command where
+  the error happens. Unfortunately, the position that breaks is not
+  always the line or command that really introduced the bug. In some
+  instances the actual error hides a few lines above.
 \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
   doing.
@@ -268,11 +268,11 @@ solve the problem.
   specific line and proceed step by step. Be sceptical and test all
   steps for correctness.
 \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
-  programmer or exactly understands what is going on. Often it is the
-  own refelction on the probelem and the chosen approach that helps
-  finding the bug. (This is strategy is also known as \codeterm{Rubber
+  programmer or exactly understands what is going on. Often, it is the
+  own reflection on the problem and the chosen approach that helps
+  finding the bug. (This strategy is also known as \codeterm{Rubber
     duck debugging}.
 \end{enumerate}
 
@@ -280,24 +280,26 @@ solve the problem.
 \subsection{Debugger}
 
 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
-of the editor window is green or orange, you can set on or several
-\codeterm{break point}s. When the porgram is executed by calling it
+of the editor window is green or orange, you can set one or several
+\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
 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}).
 
 \begin{figure}
   \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
-    saved and passes the syntax check the green indicator (top-right
-    corner of the editor window), a breakpoint can be set. Breakpoints
-    can bes set either using the dropdown menu on top or by clicking
-    the line number on the left margin. An active breakpoint is
-    indicated by a red dot.}\label{editor_debugger}
+    saved and passes the syntax check (the indicator in the top-right
+    corner of the editor window turns green or orange), a breakpoint
+    can be set. Breakpoints can be set either using the dropdown menu
+    on top or by clicking the line number on the left margin. An
+    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}
 
 
@@ -308,17 +310,17 @@ K>>
 \end{lstlisting}
 
 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
-the state of a variable can be altered or even deleted which might
-affect the execution of the remaining code.
+program at this point, we can also issue commands to try the next
+steps etc. Beware however, the state of a variable can be altered or
+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:
 \begin{enumerate}
 \item \textbf{Continue} --- simply move on until the program terminates or the
   execution reaches the next breakpoint.
 \item \textbf{Step} --- Execute the next command and stop.
-\item \textbf{Step in} --- If the next command is the execution of a
-  function step into it and stop at the first command.
+\item \textbf{Step in} --- If the next command is a
+  function call, step into it and stop at the first command.
 \item \textbf{Step out} --- If the next command is a function call,
   proceed until the called function returns, then stop.
 \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}
 
 The debugger offers some more (advanced) features but the
-functionality offered by the basic tools is often enough to debug the
-code.
+functionality offered by the basic tools is often enough to debug a program.