From bdb673b6eb6269339fea35386147b2988565ada1 Mon Sep 17 00:00:00 2001
From: "Dr. Martin Goik" <goik@hdm-stuttgart.de>
Date: Sun, 3 Nov 2019 08:31:50 +0100
Subject: [PATCH] Moving static code analysis exercise

---
 Doc/Sd1/objectsClasses.xml | 211 +++++++++++++++++++++++++++++++++++++
 Doc/Sd1/statements.xml     | 156 ---------------------------
 2 files changed, 211 insertions(+), 156 deletions(-)

diff --git a/Doc/Sd1/objectsClasses.xml b/Doc/Sd1/objectsClasses.xml
index 52108740a..379e4ad74 100644
--- a/Doc/Sd1/objectsClasses.xml
+++ b/Doc/Sd1/objectsClasses.xml
@@ -868,6 +868,217 @@ System.out.println("Perimeter=" + r.getPerimeter());</programlisting></td>
       </informaltable>
     </figure>
 
+    <qandaset defaultlabel="qanda" xml:id="sd1_qanda_missingReturn">
+      <title>Compile time error</title>
+
+      <qandadiv>
+        <qandaentry>
+          <question>
+            <para>Try to compile the following snippet:</para>
+
+            <programlisting language="java">public int getMinimum(int a, int b) {
+  if (a &lt; b) {
+    return a;
+  } 
+}</programlisting>
+
+            <para>You'll encounter a Missing return statement error. What's
+            wrong here?</para>
+          </question>
+
+          <answer>
+            <para>The compiler effectively complains about a missing <code
+            language="java">if</code> related path: In case of <code
+            language="java">b &lt;= a</code> no return value has been defined.
+            There are two possible solutions:</para>
+
+            <orderedlist>
+              <listitem>
+                <programlisting language="java">public int getMinimum(int a, int b) {
+  if (a &lt; b) {
+    return a;
+  } else {
+    return b;
+  }
+}</programlisting>
+              </listitem>
+
+              <listitem>
+                <para>Less readable but still producing an identical
+                result:</para>
+
+                <programlisting language="java">public int getMinimum(int a, int b) {
+  if (a &lt; b)
+    return a;
+  return b;
+}</programlisting>
+              </listitem>
+            </orderedlist>
+          </answer>
+        </qandaentry>
+      </qandadiv>
+    </qandaset>
+
+    <qandaset defaultlabel="qanda"
+              xml:id="sd1_qanda_staticCodeAnalysisUnreachable">
+      <title>Static code analysis</title>
+
+      <qandadiv>
+        <qandaentry>
+          <question>
+            <para>Consider the following snippet:</para>
+
+            <programlisting language="java">int count = 3;
+
+count++;
+
+if (count &lt; 5)
+    return;
+    return;
+
+System.out.println("Failed!");</programlisting>
+
+            <para>This <xref linkend="glo_Java"/> code resembles the <link
+            xlink:href="https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-goto-fail-apples-ssl-bug-explained-plus-an-unofficial-patch/">Apple
+            goto fail SSL bug</link>'s structural problem. Since <xref
+            linkend="glo_Java"/> does not (yet) offer <code>goto</code>
+            statements we use <code language="java">return</code> instead for
+            terminating the <quote>current</quote> context.</para>
+
+            <para>Copy this code into your <xref linkend="glo_IDE"/>
+            and:</para>
+
+            <orderedlist>
+              <listitem>
+                <para>Explain the resulting error. What is wrong? How do you
+                correct this error?</para>
+              </listitem>
+
+              <listitem>
+                <para>Explain the <code language="java">count++</code>
+                statement's purpose.</para>
+
+                <tip>
+                  <para>There is no <quote>real</quote> application logic in
+                  the given code. This example is meant to explain formal
+                  <xref linkend="glo_Java"/> language features. What happens
+                  if you correct the compile time error and in addition purge
+                  the <code language="java">count++</code> statement?</para>
+                </tip>
+              </listitem>
+
+              <listitem>
+                <para>What is the underlying idea of these warning and error
+                messages?</para>
+              </listitem>
+            </orderedlist>
+          </question>
+
+          <answer>
+            <orderedlist>
+              <listitem>
+                <para>Like in the <link
+                xlink:href="https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-goto-fail-apples-ssl-bug-explained-plus-an-unofficial-patch/">Apple
+                goto fail SSL bug</link> the code is poorly indented. Using
+                your <xref linkend="glo_IDE"/>'s auto indenting feature (Do
+                it!) you get:</para>
+
+                <programlisting language="java">int count = 3;
+count++;
+
+if (count &lt; 5)
+    return;
+return;
+
+System.out.println("Failed!");</programlisting>
+
+                <para>The second <code language="java">return</code> statement
+                will leave the given context unconditionally regardless of the
+                preceding <code language="java">if (count &lt; 5)</code> and
+                the <code language="java">count</code> variable's value in
+                particular. Thus the final <code
+                language="java">System.out.println("Failed!") statement</code>
+                being unreachable results in a compile time error.</para>
+
+                <para>Removing the erroneous second <code
+                language="java">return</code> statement resolves the error
+                leaving us with happily compiling code:</para>
+
+                <programlisting language="java">int count = 3;
+count++;
+
+if (count &lt; 5)
+    return;
+
+System.out.println("Failed!");</programlisting>
+
+                <para>Conclusion: The <link
+                xlink:href="https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-goto-fail-apples-ssl-bug-explained-plus-an-unofficial-patch/">Apple
+                goto fail SSL bug</link> could not have been occurring in
+                <xref linkend="glo_Java"/> due to an inherent language
+                feature. </para>
+              </listitem>
+
+              <listitem>
+                <para>Removing <code language="java">count++</code> leaves us
+                with:</para>
+
+                <programlisting language="java">int count = 3;
+
+if (count &lt; 5) <co linkends="sd1_callout_staticIfAlwaysTrue-1"
+                    xml:id="sd1_callout_staticIfAlwaysTrue-1-co"/>
+    return;
+
+System.out.println("Failed!");</programlisting>
+
+                <calloutlist>
+                  <callout arearefs="sd1_callout_staticIfAlwaysTrue-1-co"
+                           xml:id="sd1_callout_staticIfAlwaysTrue-1">
+                    <para>Compiler warning: <emphasis role="bold">Condition
+                    'count &lt; 5' is always 'true'</emphasis>.</para>
+                  </callout>
+                </calloutlist>
+
+                <para>This warning is due to static compile time code
+                analysis: The <code language="java">count</code> variable's
+                value is not being altered throughout its scope. It could
+                actually be declared as <code language="java">final int count
+                = 3 disallowing since no sub</code>sequent assignments occur.
+                Thus the <code language="java">return</code> inside the <code
+                language="java">if (count &lt; 5)</code> clause will always be
+                executed.</para>
+
+                <note>
+                  <para>Despite its simplicity having the count++ statement in
+                  place defeats the compiler's ability to discover<code
+                  language="java"> our variable count</code>'s value now being
+                  4 is still smaller than 5.</para>
+                </note>
+              </listitem>
+
+              <listitem>
+                <para>This mechanism keeps programmers from coding carelessly:
+                Even the <code language="java">if (count &lt; 5)</code>
+                statement is most likely an unintended bug.</para>
+              </listitem>
+            </orderedlist>
+
+            <important>
+              <para>Conclusion: Watch out for compiler warning messages and do
+              not ignore them!</para>
+
+              <para>In many cases compiler warnings reveal serious flaws.
+              Correction on average will save you cumbersome time debugging
+              your code.</para>
+
+              <para>Set your compiler / <xref linkend="glo_IDE"/>'s warnings
+              to a yet tolerable higher level.</para>
+            </important>
+          </answer>
+        </qandaentry>
+      </qandadiv>
+    </qandaset>
+
     <section xml:id="sd1_sect_accessControl">
       <title>Encapsulation and access control</title>
 
diff --git a/Doc/Sd1/statements.xml b/Doc/Sd1/statements.xml
index b6c433875..13dc3bf16 100644
--- a/Doc/Sd1/statements.xml
+++ b/Doc/Sd1/statements.xml
@@ -881,162 +881,6 @@ err = sslRawVerify(...);  ...</programlisting></td>
         </informaltable>
       </figure>
 
-      <qandaset defaultlabel="qanda"
-                xml:id="sd1_qanda_staticCodeAnalysisUnreachable">
-        <title>Static code analysis</title>
-
-        <qandadiv>
-          <qandaentry>
-            <question>
-              <para>Consider the following snippet:</para>
-
-              <programlisting language="java">int count = 3;
-count++;
-
-if (count &lt; 5)
-    return;
-    return;
-
-System.out.println("Failed!");</programlisting>
-
-              <para>This <xref linkend="glo_Java"/> code mimics the <link
-              xlink:href="https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-goto-fail-apples-ssl-bug-explained-plus-an-unofficial-patch/">Apple
-              goto fail SSL bug</link>'s structural problem. Since <xref
-              linkend="glo_Java"/> does not offer <code>goto</code> statements
-              we use <code language="java">return</code> instead for
-              terminating the <quote>current</quote> context.</para>
-
-              <para>Copy this code into your <xref linkend="glo_IDE"/>
-              and:</para>
-
-              <orderedlist>
-                <listitem>
-                  <para>Explain the resulting error. What is wrong? How do you
-                  correct this error?</para>
-                </listitem>
-
-                <listitem>
-                  <para>Explain the <code language="java">count++</code>
-                  statement's purpose.</para>
-
-                  <tip>
-                    <para>There is no <quote>real</quote> application logic in
-                    the given code. It is an example meant to explain formal
-                    <xref linkend="glo_Java"/> language features. What happens
-                    if you correct the compile time error and in addition
-                    purge the <code language="java">count++</code>
-                    statement?</para>
-                  </tip>
-                </listitem>
-
-                <listitem>
-                  <para>What is the underlying idea of these warning and error
-                  messages?</para>
-                </listitem>
-              </orderedlist>
-            </question>
-
-            <answer>
-              <orderedlist>
-                <listitem>
-                  <para>Like in the <link
-                  xlink:href="https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-goto-fail-apples-ssl-bug-explained-plus-an-unofficial-patch/">Apple
-                  goto fail SSL bug</link> the code is poorly indented. Using
-                  your <xref linkend="glo_IDE"/>'s auto formatting feature
-                  (how?) you get:</para>
-
-                  <programlisting language="java">int count = 3;
-count++;
-
-if (count &lt; 5)
-    return;
-return;
-
-System.out.println("Failed!");</programlisting>
-
-                  <para>The second <code language="java">return</code>
-                  statement will leave the context unconditionally regardless
-                  of the preceding <code language="java">if (count &lt;
-                  5)</code> and the <code language="java">count</code>
-                  variable's value in particular. Thus the final <code
-                  language="java">System.out.println("Failed!")</code>
-                  <emphasis role="bold">can</emphasis> never be reached
-                  resulting in a compile time error.</para>
-
-                  <para>Removing the erroneous <code
-                  language="java">return</code> resolves the error leaving us
-                  with happily compiling code:</para>
-
-                  <programlisting language="java">int count = 3;
-count++;
-
-if (count &lt; 5)
-    return;
-
-System.out.println("Failed!");</programlisting>
-
-                  <para>Conclusion: The <link
-                  xlink:href="https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-goto-fail-apples-ssl-bug-explained-plus-an-unofficial-patch/">Apple
-                  goto fail SSL bug</link> could not have been occurring in
-                  <xref linkend="glo_Java"/> due to language features.</para>
-                </listitem>
-
-                <listitem>
-                  <para>Removing <code language="java">count++</code> leaves
-                  us with:</para>
-
-                  <programlisting language="java">int count = 3;
-
-if (count &lt; 5) <co linkends="sd1_callout_staticIfAlwaysTrue-1"
-                      xml:id="sd1_callout_staticIfAlwaysTrue-1-co"/>
-    return;
-
-System.out.println("Failed!");</programlisting>
-
-                  <calloutlist>
-                    <callout arearefs="sd1_callout_staticIfAlwaysTrue-1-co"
-                             xml:id="sd1_callout_staticIfAlwaysTrue-1">
-                      <para>Compiler warning: <emphasis role="bold">Condition
-                      'count &lt; 5' is always 'true'</emphasis>.</para>
-                    </callout>
-                  </calloutlist>
-
-                  <para>This warning is due to static compile time code
-                  analysis: The <code language="java">count</code> variable's
-                  value is not being altered throughout its scope. It could
-                  actually be declared as <code language="java">final int
-                  count = 3 disallowing sub</code>sequent assignments. Thus
-                  the <code language="java">return</code> inside <code
-                  language="java">if (count &lt; 5)</code> will always be
-                  executed.</para>
-
-                  <para>Despite its simplicity having the count++ statement in
-                  place defeats the compiler's ability to discover that <code
-                  language="java">count</code> now having a value of 4 still
-                  being smaller than 5.</para>
-                </listitem>
-
-                <listitem>
-                  <para>The underlying idea is preventing programmers from
-                  coding carelessly: Even the <code language="java">if (count
-                  &lt; 5)</code> statement is most likely an unintended
-                  bug.</para>
-                </listitem>
-              </orderedlist>
-
-              <important>
-                <para>Conclusion: Watch out for compiler warning messages and
-                do not ignore them!</para>
-
-                <para>In many cases compiler warnings reveal serious flaws.
-                Correction on average will save you lots of cumbersome time
-                debugging your code.</para>
-              </important>
-            </answer>
-          </qandaentry>
-        </qandadiv>
-      </qandaset>
-
       <figure xml:id="sd1_fig_ifElseNested">
         <title>Nested <code language="java">if ... else</code></title>
 
-- 
GitLab