Galileo Computing < openbook >
Galileo Computing - Programming the Net
Galileo Computing - Programming the Net


Java ist auch eine Insel (2. Aufl.) von Christian Ullenboom
Programmieren für die Java 2-Plattform in der Version 1.4
Java ist auch eine Insel (2. Auflage)
gp Kapitel 26 Style-Guide
  gp 26.1 Programmierrichtlinien
  gp 26.2 Allgemeine Richtlinien
  gp 26.3 Quellcode kommentieren
    gp 26.3.1 Bemerkungen über JavaDoc
    gp 26.3.2 Gotcha-Schlüsselwörter
  gp 26.4 Bezeichnernamen
    gp 26.4.1 Ungarische Notation
    gp 26.4.2 Vorschlag für die Namensgebung
  gp 26.5 Formatierung
    gp 26.5.1 Einrücken von Programmcode – die Vergangenheit
    gp 26.5.2 Verbundene Ausdrücke
    gp 26.5.3 Kontrollierter Datenfluss
    gp 26.5.4 Funktionen
  gp 26.6 Ausdrücke
  gp 26.7 Anweisungen
    gp 26.7.1 Schleifen
    gp 26.7.2 Switch, case und Durchfallen
  gp 26.8 Reihenfolge der Eigenschaften in Klassen
  gp 26.9 Zugriffsrechte und Zugriffsmethoden
    gp 26.9.1 Accessors/Zugriffsmethoden
  gp 26.10 Verweise


Galileo Computing

26.7 Anweisungen  downtop

Zu den Einrückungen von Anweisungen, insbesondere den Kontrollstrukturen, wurde schon weiter vorn in diesem Kapitel etwas gesagt. Wir wollen an dieser Stelle auf die einzelnen Elemente eingehen.


Galileo Computing

26.7.1 Schleifen  downtop

Der Einsatz der Schleifen hängt natürlich von ihrem Verwendungszweck ab. for-Schleifen sollten immer dann benutzt werden, wenn eine Variable um eine konstante Größe erhöht wird. Tritt in der Schleife keine Schleifenvariable auf, die inkrementiert oder dekrementiert wird, sollte eine while-Schleife genutzt werden. Eine do/while-Schleife sollte dann ihren Einsatz finden, wenn die Abbruchbedingung erst am Ende eines Schleifendurchlaufs ausgewertet werden kann. Variablen, die eine Größe oder Länge bezeichnen, können beim Durchlauf unrealistischerweise negative Werte annehmen. Leider können in Java keine Typen ohne Vorzeichen deklariert werden – lassen wir char einmal außen vor –, so wie in C für viele Datentypen unsigned erlaubt ist.

Für Bereichsangaben der Form a>=23 && a<=42 ist es empfehlenswert, den unteren Wert mit in den Vergleich einzubeziehen, den Wert für die obere Grenze jedoch nicht (inklusive untere Grenzen und exklusive obere Grenzen). Für unser Beispiel, in dem a im Intervall bleiben soll, ist Folgendes besser: a>=23 && a<43. Die Begründung dafür ist einleuchtend:

gp  Die Größe des Intervalls ist die Differenz aus den Grenzen.
gp  Ist das Intervall leer, so sind die Intervallgrenzen gleich.
gp  Die untere Grenze ist nie größer als die obere Grenze.

Die Standard-Bibliothek verwendet diese Konvention auch durchgängig bei substring(), subList() oder Array-Indexwerten.

Die Vorschläge können für normale Schleifen mit Vergleichen übernommen werden. So ist eine Schleife mit zehn Durchgängen besser in der Form

for ( a = 0; a < 10; a++ )

formuliert als in der semantisch äquivalenten Form

for ( a = 0; a <= 9; a++ )

Das Schlüsselwort continue

Wir können unsere Programme lesbarer machen, indem wir auf continue verzichten. Außerdem können wir ein break benutzen, anstatt mit Flags aus einer Schleife vorzeitig auszubrechen. Dazu zwei Beispiele. Folgendes ist zu vermeiden:

boolean endFlag = false;

do
{
  if ( Bedingung )
  {
    // Code ohne Ende
    endFlag = true;
  }
} while ( weitereBedingung && !endFlag );

stattdessen schreiben wir:

do
{
  if ( Bedingung )
  {
    // Code wieder ohne Ende
    break;
  }
} while ( weitereBedingung );

Die alternative Lösung macht natürlich einen Unterschied, falls nach dem if noch Anweisungen in der Schleife stehen.

Ein continue am Ende einer if-Abfrage kann durch einen else-Teil bedeutend klarer gefasst werden. Zunächst das schlechte Beispiel:

while ( Bedingung )       // Durch continue verzuckert
{
  if ( NochNeBedingung )
  {
    // Code,Code, code
    continue;
  }
  // Weiterer schöner Code
}

Viel deutlicher ist:

while ( Bedingung )
{
  if ( NochNeBedingung )
  {
    // Code, Code, Code
  }
  else
  {
    // Weiterer schöner Code
  }
}

Galileo Computing

26.7.2 Switch, case und Durchfallen  toptop

Es ist eine Eigenschaft der case-Zweige einer switch-Anweisung, dass ein Zweig, der nicht durch ein break abgeschlossen ist, im nächsten case-Zweig weiter ausgeführt wird. Dies ist eine große Fehlerquelle. Wir betrachten wieder ein Beispiel:

switch ( Tag )
{
  case A:
  // Code, der durchfällt

  case B:
    lieblingsFunktion();
    // und noch Code dazu
    break;             // jetzt erst switch-Anweisung verlassen

  case C:
}

Günstiger ist es, die absichtlich durchfallenden case-Zweige kenntlich zu machen, beispielsweise so:

switch ( Tag )
{
  case A:
    // Code, der durchfällt
    // FALLTHROUGH                      FALLTHROUGH

  case B:
    lieblingsFunktion();
    // und noch Code dazu
    break;             // jetzt erst switch-Anweisung verlassen

  case C:
}




Copyright © Galileo Press GmbH 2003
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press GmbH, Gartenstraße 24, 53229 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de