Programmieren am KIT

Im ersten Semester des Informatikstudiums am KIT besucht man üblicherweise die Vorlesung Programmieren. Diese soll grundlegende Konzepte der Programmierung am Beispiel von Java vermitteln.

Hier ein paar Tipps von mir:

Benutzt Git.
Schreibt viele Tests. Erweitert dazu zum Beispiel die Terminalklasse so, dass diese Textdateien einliest, in denen Eingaben und erwartete Ausgaben stehen. Außerdem gibt es eine Onlinetestumgebung, in der mehrere Nutzer Testfälle beitragen können.
An vielen Stellen ist es sinnvoll, reguläre Ausdrücke zu verwenden. Diese werden schnell unübersichtlich. Mit dem Onlinetool Debuggex kann man sie testen und visualisieren.
Benutzt möglichst abstrakte Datentypen, also z. B. Collection statt LinkedList, wo immer das möglich ist.
Trennt UI und Logik (Stichwort Entwurfsmuster Fassade), am besten in zwei Paketen.
Benutzt keine Magic Numbers und lagert Ausgabetexte in separate Klassen aus. Mit eigenen Checkstyle-Regeln kann man solche Fälle erkennen lassen.
Verzichtet auf Plagiate. Es findet auch eine automatisierte Prüfung statt.
Es gibt keine Extrapunkte für besonders „anspruchsvolle“ Lösungen, sondern nur Abzug für Fehler. Haltet euch deshalb genau an die Aufgabenstellungen und die Hinweise zu Stil und Aufbau aus der Vorlesung, den Tutorien und dem Wiki.
Versucht, möglichst viele Fehlerarten automatisch erkennen zu lassen, zum Beispiel durch eigene Checkstyle-Regeln oder die Code-Inspektionen von IntelliJ IDEA.

Damit ihr einen Eindruck vom Umfang der Abschlussaufgaben bekommt, findet ihr hier meine Lösungen aus dem Wintersemester 2018/19.

Wer ein ähnliches Projekt vor sich hat, kann sich an der Struktur dieser Lösungen orientieren, wobei die CommandFactory in meiner Lösung wohl doch ein bisschen zu umfangreich ist. Eine einfachere, weniger flexible Lösung wäre für eine Abgabe wohl die bessere Wahl. Meine Lösungen wurden mit 1,0 bewertet.

Neben der Funktionalität wird auch die Methodik bewertet. Die folgende Liste stammt von der Übungsleitung und nennt typische Kritikpunkte. Weder Aktualität noch Vollständigkeit werden garantiert:

Die implementierte Logik ist nicht variabel, weil z. B. viele Parameter hartkodiert sind (Magic Numbers).
Tief verschachtelte Codestellen ließen sich sinnvoll durch private Hilfsmethoden strukturieren.
Attribute sind nicht als final deklariert, obwohl sie es sein könnten.
Statische Methoden oder Attribute sollten eigentlich Instanzmethoden oder Instanzattribute sein.
Methoden oder Attribute haben eine falsche Sichtbarkeit und sollten eigentlich private sein.
Zugriffsmethoden geben Implementierungsdetails preis und verletzen damit die Kapselung, z. B. bei Arrays oder Listen.
Die objektorientierte Modellierung wird nicht konsequent angewandt.
Code wird kopiert, statt gemeinsame Funktionalität in einer Hilfsmethode oder Oberklasse zusammenzufassen.
Terminalausgaben sind nicht in einer UI-Klasse verkapselt, sondern über die Domänenklassen verteilt oder stark mit der Logik vermischt.
Objekte werden über Strings statt über typisierte Java-Referenzen referenziert.
Als Typ wird eine konkrete Klasse statt eines Interfaces gewählt.
Die Javadoc-Kommentare sind leer oder beschreiben nur Triviales. Insbesondere fehlen Angaben zu Fehlerfällen, etwa dazu, wann Exceptions geworfen werden. (Für geerbte Methoden sind keine eigenen Javadoc-Kommentare erforderlich.)
An sehr komplexen Codestellen fehlen erklärende Kommentare, oder die Stellen sollten durch geeignete Hilfsmethoden strukturiert werden.
Importanweisungen verwenden Wildcards.
Der gewählte Schleifentyp ist ungeeignet, z. B. while statt for oder eine klassische for-Schleife statt einer For-each-Schleife.
Der Code enthält auskommentierte Quelltextschnipsel, TODOs oder unangemessene Kommentare.
Exceptions werden zur Steuerung des Kontrollflusses verwendet.
try/catch-Blöcke sind zu groß und umfassen mehr als die nötigen Konstrukte.
IndexOutOfBoundsException oder NullPointerException werden abgefangen, statt zuvor zu prüfen, ob der Index gültig beziehungsweise die Referenz ungleich null ist.