Commit 031c19f6 authored by Andreas Zwinkau's avatar Andreas Zwinkau
Browse files

Implementierung.Sonstiges

parent 992ae0ad
......@@ -395,6 +395,39 @@ Paradoxe Anforderungen zeigen, dass gutes Design ein Kunst ist.
Es sollen nicht ganze Testszenarien getestet werden.
\end{itemize}
\subsection{Sonstiges}
\begin{itemize}
\item Warnungen reparieren.
Es ist empfehlenswert,
dass ein Projekt beim Bauen keine Warnungen ausgibt.
Eine Warnung bedeutet,
dass der Code üblicherweise aber nicht garantiert fehlerhaft ist.
In Ausnahmen kann der Programmierer in Java
dann Annotationen einfügen um Warnungen zu unterdrücken.
\item Warnungen anschalten.
In Eclipse kann man zusätzliche Warnungen anschalten:
Project properties
$\rightarrow$ Java Compiler
$\rightarrow$ Errors/Warnings.
Standardmäßig wird das meiste ignoriert.
Beispielsweise kann man aktivieren,
dass eine Zuweisung innerhalb einer Bedingung \enquote{\texttt{if(a=b)}} eine Warnung (oder sogar ein Fehler) ist.
\item Kommentare im Code (also nicht API Doku)
sollten das \enquote{Warum} klären,
nicht das \enquote{Wie}.
Es ist naturgemäß schwierig vorherzusehen,
welche Warum-Fragen sich jemand stellt,
der ein Stück Code liest.
Die Fragen sind üblicherweise
\enquote{Warum ist X hier notwendig?},
\enquote{Warum ist kein X hier?} oder
\enquote{Warum X, wobei Y doch besser wäre?}.
\item Exceptions (nicht RuntimeException) für Fehler beim Aufrufer.
Assertions für interne Konsistenzfehler
bzw. um Annahmen explizit zu machen.
\end{itemize}
\section{Qualitätssicherung}
\dictum[Edsger Dijkstra]{
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment