Programmierstil

Programmierstil

Talk is cheap, show me the code
Linus Torvalds
Don't comment bad code – rewrite it!
Brian W. Kernighan

Beispiel: Schlechter Stil 

public class Div{static $1 $_;class $1{void _$(String $_){System.//
out.print($_);}$1(){_();}void _(){int _,$,_$,$$,__,ä=(1<<5),
å=100,ö=12,åö=ä*ö;å-=1<<4;while(åö>0){for($$=_$=_=__=$=(int)
å;_$>($$-(1<<2));_$(""+(char)(_$)),_$-=1<<1)for(_=$=__-9;_>(
$-6);_-=1<<1,_$(""+(char)(_$!=å?_:ä)));char S$=(char)(å+ö+1)
;_$("te"+S$+(char)(ö+(int)S$));åö--;}}}Div(){$_=new $1();}
public static void main(String []$){Div å=new Div();}

Motivation

Nicht der Compiler ist das Publikum, sondern Menschen, die den Source Code lesen müssen!

Probleme mit schlechtem Programmierstil

  • Teamarbeit wird durch inkonsistenten Stil erschwert
  • Programme sind fehleranfälliger
  • Änderungen am Programm werden erschwert
  • Lesen des Source-Codes ist eine Qual
  • Punktabzug bei den Pflichtübungen ;-)

Es gibt mehrere Gründe, warum es wichtig ist, einen guten, einheitlichen Programmierstil zu haben:

  1. Lesbarkeit: Wenn ein(e) Programmierer:in einen konsistenten Stil verwendet, der leicht zu lesen und zu verstehen ist, können andere Entwickler:innen schneller erkennen, was der Code macht und wie er funktioniert. Dies führt zu einem schnelleren Verständnis und einer schnelleren Fehlerbehebung.
  2. Wartbarkeit: Ein einheitlicher Programmierstil erleichtert die Wartung des Codes, da es einfacher ist, Fehler zu finden und Änderungen vorzunehmen.
  3. Zusammenarbeit: Ein konsistenter Stil erleichtert die Zusammenarbeit und das Verständnis des Codes, da alle Entwickler:innen den Code auf die gleiche Weise lesen und interpretieren.
  4. Effizienz: Wenn Entwickler:innen denselben Stil verwenden, können sie schneller arbeiten, da sie sich nicht mit unterschiedlichen Stilen auseinandersetzen müssen. Dies führt zu einer höheren Effizienz und einer schnelleren Entwicklung von Software.
  5. Professionalität: Ein konsistenter Stil zeigt, dass die Entwickler:innen professionell sind und dass sie sich Gedanken darüber gemacht haben, wie der Code präsentiert wird.

Java Coding Standard

Code grundsätzlich nach Coding-Standard formatieren!

  • Keine TABs verwenden, Einrückung pro Ebene 4 Leerzeichen
  • Zeilenlänge maximal 80 Zeichen
  • Klassennamen beginnen mit Großbuchstaben
  • Methodennamen beginnen mit Kleinbuchstaben
  • Variablennamen beginnen mit Kleinbuchstaben
  • KONSTANTEN werden großgeschrieben
  • Pro Zeile nur eine Deklaration bzw. ein Statement
  • CamelCase für zusammengesetzte Namen

Sie finden den Coding-Standard für Java hier.

Beispiel: Guter Stil 

package de.smits_net.pr2;

/**
 * Klasse dient als Beispiel für den Coding-Standard und die
 * Namenskonventionen bei Java-Programmen.
 *
 * @author Thomas Smits
 */
public class CodingStandard {

    /**
     * Konstante, die dem Rest der Welt etwas mitteilen soll.
     */
    public static final int KONSTANTE_MIT_TOLLEM_WERT = 3;

    private int erstesFeld;
    private double zweitesFeld;

    /**
     * Methode, die etwas tut - oder nicht ;-).
     *
     * @param parameter Eingabewert für die Methode
     * @return gibt immer 42 zurück
     */
    public int methodeDieWasTut(int parameter) {

        if (parameter > 3) {
            erstesFeld = 12;
        }
        else {
            zweitesFeld = 13;
        }

        return 42;
    }
}

Boolesche Rückgabewerte

So schön Kontrollstrukturen sind, man braucht sie nicht immer. Ein klassischer Fehler ist, mit einem if einen booleschen Rückgabewert zu bestimmen. Solche Konstrukte kann man immer durch einen einfachen Ausdruck ersetzen.

Schlecht
if (bedingung) {
  return true;
}
else {
  return false;
}
Gut
return bedingung;
Schlecht
if (bedingung) {
  return false;
}
else {
  return true;
}
Gut
return !bedingung;
Schlecht
return bedingung ? true : false;
Gut
return bedingung;
Schlecht
return bedingung ? false : true;
Gut
return !bedingung;

Weitere Regeln

  • Minimale Sichtbarkeit von Methoden und Feldern (nur public wenn wirklich nötig)
  • Verbergen Sie Implementierungsdetails (Information Hiding)
  • Dokumentieren Sie alle öffentlichen Methoden mit JavaDoc
  • Kopieren Sie keinen Code – Don't Repeat Yourself (DRY): Doppelter Code ist eine Hauptquelle von Fehlern
  • Machen Sie keine Ausgaben auf der Konsole (Ausnahme, die Aufgabe verlangt es explizit)
  • Lesen Sie keine Daten von der Konsole ein (Scanner ade)
  • Testen Sie Ihre Klassen mit JUnit-Tests
  • Programmieren Sie mit so wenig Seiteneffekten wie möglich
  • Machen Sie Klassen (wenn möglich) immutable
  • Denken Sie genau nach, was Sie in Attributen und was Sie in lokalen Variablen speichern
  • Fangen Sie mögliche Fehler korrekt ab
  • Denken Sie vor allem an die Randfälle und vertrauen Sie niemals den Eingabedaten
  • Halten Sie Daten und Methoden zusammen (Abstrakte Datentypen)
  • Vermeiden Sie komplexen und komplizierten Code
  • Kommentieren Sie keinen Code aus: verwenden Sie ein Versionsverwaltungssystem, um alte Stände vorzuhalten
  • Lassen Sie keine // TODO-Kommentare im Quellcode stehen
  • Erzeugen Sie keine leeren Catch-Blöcke
  • Benennen Sie Methoden nach dem Schema Verb oder Verb + Nomen, z. B. copy, copyFile, removeEntry
  • Verwenden Sie Konstanten anstatt magischer Werte

Einige der Regeln greifen vor, d. h. die dahinterliegende Theorie ist noch gar nicht eingeführt. Trotzdem werden sie hier bereits erwähnt, damit am Ende der Vorlesung alle Regeln an einer Stelle zusammengefasst sind.

Magische Werte sind Werte (z. B. 42), die direkt im Code verwendet werden, ohne als Konstanten definiert zu werden. Diese Werte können schwer zu finden und zu ändern sein und können zu Fehlern führen, wenn sich ihre Bedeutung im Laufe der Zeit ändert. Benannte Konstanten (z. B. ANTWORT_AUF_ALLES) hingegen können leicht gefunden und geändert werden, da sie an einer zentralen Stelle definiert sind und an verschiedenen Stellen im Code verwendet werden können. Obwohl magische Werte möglicherweise weniger Code erfordern, ist es wichtig, benannte Konstanten zu verwenden, um Fehlerquellen zu minimieren.

Copyright © 2025 Thomas Smits