improved indices

debugging/lecture/debugging.tex

@@ -6,10 +6,10 @@
 When writing a program from scratch we almost always make
 mistakes. Accordingly, a quite substantial amount of time is invested
 into finding and fixing errors. This process is called
-\codeterm{debugging}. Don't be frustrated that a self-written program
-does not work as intended and produces errors. It is quite exceptional
-if a program appears to be working on the first try and, in fact,
-should leave you suspicious.
+\entermde{Debugging}{debugging}. Don't be frustrated that a
+self-written program does not work as intended and produces errors. It
+is quite exceptional if a program appears to be working on the first
+try and, in fact, should leave you suspicious.
 
 In this chapter we will talk about typical mistakes, how to read and
 understand error messages, how to actually debug your program code and
@@ -20,7 +20,7 @@ some hints that help to minimize errors.
 There are a number of different classes of programming errors and it
 is good to know the common ones. Some of your programming errors will
 will lead to violations of the syntax or to invalid operations that
-will cause \matlab{} to \codeterm{throw} an error. Throwing an error
+will cause \matlab{} to \code{throw} an error. Throwing an error
 ends the execution of a program and there will be an error messages
 shown in the command window. With such messages \matlab{} tries to
 explain what went wrong and to provide a hint on the possible cause.
@@ -30,8 +30,9 @@ are generally easier to find and to fix than logical errors that stay
 hidden and the results of, e.g. an analysis, are seemingly correct.
 
 \begin{important}[Try --- catch]
-  There are ways to \codeterm{catch} errors during \codeterm{runtime}
-  (i.e. when the program is executed) and handle them in the program.
+  There are ways to \code{catch} errors during \enterm{runtime}
+  (\determ{Laufzeit}, i.e. when the program is executed) and handle
+  them in the program.
 
 \begin{lstlisting}[label=trycatch, caption={Try catch clause}]
   try
@@ -43,15 +44,15 @@ hidden and the results of, e.g. an analysis, are seemingly correct.
 
 This way of solving errors may seem rather convenient but is
 risky. Having a function throwing an error and catching it in the
-\codeterm{catch} clause will keep your command line clean but may
-obscure logical errors! Take care when using the \codeterm{try-catch
-  clause}.
+\code{catch} clause will keep your command line clean but may obscure
+logical errors! Take care when using the \code{try}-\code{catch}
+clause.
 \end{important}
 
 
 \subsection{Syntax errors}\label{syntax_error}
 The most common and easiest to fix type of error. A
-\entermde[error!syntax]{Fehler!Syntax\~}{syntax error} violates the
+\entermde[error!syntax]{Fehler!Syntax@Syntax\texttildelow}{syntax error} violates the
 rules (spelling and grammar) of the programming language. For example
 every opening parenthesis must be matched by a closing one or every
 \code{for} loop has to be closed by an \code{end}. Usually, the
@@ -69,7 +70,7 @@ Did you mean:
 
 \subsection{Indexing error}\label{index_error}
 Second on the list of common errors are the
-\entermde[error!indexing]{Fehler!Index\~}{indexing errors}. Usually
+\entermde[error!indexing]{Fehler!Index@Index\texttildelow}{indexing errors}. Usually
 \matlab{} gives rather precise infromation about the cause, once you
 know what they mean. Consider the following code.
 
@@ -108,21 +109,21 @@ dimensions. This indicates that we are trying to read data behind the
 length of our variable \varcode{my\_array} which has 100 elements.
 One could have expected that the character is an invalid index, but
 apparently it is valid but simply too large. The fith attempt finally
-succeeds. But why? \matlab{} implicitely converts the \codeterm{char}
-to a number and uses this number to address the element in
-\varcode{my\_array}. The \codeterm{char} has the ASCII code 65 and
-thus the 65th element of \varcode{my\_array} is returned.
+succeeds. But why? \matlab{} implicitely converts the character to a
+number and uses this number to address the element in
+\varcode{my\_array}. The character \varcode{'A'} has the ASCII code 65
+and thus the 65th element of \varcode{my\_array} is returned.
 
 \subsection{Assignment error}
 Related to the indexing error, an
-\entermde[error!assignment]{Fehler!Zuweisungs\~}{assignment error}
-occurs when we want to write data into a variable, that does not fit
-into it. Listing \ref{assignmenterror} shows the simple case for 1-d
-data but, of course, it extents to n-dimensional data. The data that
-is to be filled into a matrix hat to fit in all dimensions. The
-command in line 7 works due to the fact, that matlab automatically
-extends the matrix, if you assign values to a range outside its
-bounds.
+\entermde[error!assignment]{Fehler!Zuweisungs@Zuweisungs\texttildelow}{assignment
+  error} occurs when we want to write data into a variable, that does
+not fit into it. Listing \ref{assignmenterror} shows the simple case
+for 1-d data but, of course, it extents to n-dimensional data. The
+data that is to be filled into a matrix hat to fit in all
+dimensions. The command in line 7 works due to the fact, that matlab
+automatically extends the matrix, if you assign values to a range
+outside its bounds.
 
 \begin{lstlisting}[label=assignmenterror, caption={Assignment errors.}]
 >> a = zeros(1, 100);
@@ -191,7 +192,7 @@ few strategies that should we can employ to solve the task.
   it. Comment, but only where necessary. Correctly indent your
   code. Use descriptive variable and function names.
 \item Keep it simple.
-\item Test your code by writing \codeterm{unit tests} that test every
+\item Test your code by writing \entermde[unit test]{Modultest}{unit tests} that test every
   aspect of your program (\ref{unittests}).
 \item Use scripts and functions and call them from the command
   line. \matlab{} can then provide you with more information. It will
@@ -264,13 +265,13 @@ The idea of unit tests to write small programs that test \emph{all}
 functions of a program by testing the program's results against
 expectations.  The pure lore of test-driven development requires that
 the tests are written \textbf{before} the actual program is
-written. In parts the tests put the \codeterm{functional
+written. In parts the tests put the \enterm{functional
   specification}, the agreement between customer and programmer, into
 code. This helps to guarantee that the delivered program works as
 specified. In the scientific context, we tend to be a little bit more
 relaxed and write unit tests, where we think them helpful and often
 test only the obvious things. To write \emph{complete} test suits that
-lead to full \codeterm{test coverage} is a lot of work and is often
+lead to full \enterm{test coverage} is a lot of work and is often
 considered a waste of time. The first claim is true, the second,
 however, may be doubted. Consider that you change a tiny bit of a
 standing program to adjust it to the current needs, how will you be
@@ -446,8 +447,8 @@ that help to solve the problem.
   line. Often, it is not necessary that the other person is a
   programmer or exactly understands what is going on. Rather, 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}).
+  finding the bug (this strategy is also known as \enterm{Rubber
+    ducking}).
 \end{enumerate}
 
 
@@ -457,11 +458,11 @@ The \matlab{} editor (figure\,\ref{editor_debugger}) supports
 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 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 to indicate that we are now stopped in
-debug mode (listing\,\ref{debuggerlisting}).
+\entermde[break point]{Haltepunkt}{break points}. 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 to indicate that we are now
+stopped in debug mode (listing\,\ref{debuggerlisting}).
 
 \begin{figure}
   \centering