Programmieren am KIT
Im ersten Semester des Informatikstudiums am KIT besucht man üblicherweise die Vorlesung Programmieren. Diese soll gundlegende Konzepte der Programmierung am Beispiel von Java einführen.
Hier ein paar Tipps von mir:
- Benutzt git
- Schreibt viele Tests. Zum Beispiel durch Erweitern der Terminalklasse, sodass diese Textdateien einliest in denen Eingaben und erwartete Ausgaben stehen. Außerdem gibt es: Eine Onlinetestumgebung in der mehrere User Testfälle beitragen können.
- An vielen Stellen ist 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 und nicht LinkedList wo immer möglich.
- Trennt UI und Logik (Stichwort Entwurfsmuster Fassade), am besten in zwei Paketen.
- Benutzt keine Magic-Numbers und lagert Ausgabetext in extra Klassen aus. Man kann sich einen Checkstyle bauen, sodass so etwas erkannt wird.
- Verzichtet auf Plagiate, es finde auch eine automatisierte Prüfung statt.
- Es gibt keine extra Punkte für besonders „anspruchsvolle“ Lösungen, sondern nur Abzug für Fehler. Es ist deshalb zu empfehlen genau das zu machen, was in den Aufgaben steht und was an Hinweisen zu Stil und Aufbau in der Vorlesung, den Tutorien, dem Wiki, etc. gegeben wurde.
- Versucht möglichst viele Fehlerarten automatisch erkennen zu lassen, zum Beispiel durch erweitern des Checkstyles oder durch den Code Inspector von IntelliJ.
Um einen Eindruck vom Umfang der Abschlussaufgaben zu bekommen hier meine Lösungen aus dem Wintersemester 18/19.
Wer ein ähnliches Projekt vor sich hat, kann sich an der Struktur dieser Aufgabe orientieren, wobei die CommandFactory in meiner Lösung wohl doch ein bisschen zu umfangreich ist. Eine simplere weniger flexiblere Lösung wäre wohl die bessere Entscheidung für eine Abgabe. Die Aufgaben wurden mit 1,0 bewertet.
Neben der Funktionalität wird auch die Methodik bewertet. Hier wird insbesondere auf folgende Punkte geachtet (Erstellt wurde diese Liste von der Übungsleitung. Weder Aktualität noch Vollständigkeit werden garantiert):
- Keine Variabilität in der implementierten Logik, z.B. viele Parameter hartkodiert (Magic-Numbers)
- Zu tiefe Verschachtelungstiefe die trivialerweise und sinnvoll in eine private Untermethode verpackt hätte werden können.
- Nicht-finale Attribute, die final sein könnten
- Statische Methode oder Attribut in einer Klasse sollte eigentlich Instanzmethode oder Attribut sein
- Falsche Sichtbarkeit: Methode oder Attribut sollte eigentlich Private sein
- Zugriffsmethoden für Implementierungsdetails (Kapselung verletzt), z.B. für Arrays oder List
- Objekt-Orientierte Modellierung nicht konsequent angewandt
- Code-Kopien, statt gemeinsame Funktionalität in Hilfsmethode oder Oberklasse
- Ausgaben auf Terminal sind nicht in einer UI-Klasse verkapselt, sondern über die Domänenklassen verteilt, oder stark gemischt mit Logik
- Objekte werden über Strings referenziert, anstatt über typisierte Java-Referenzen
- Konkrete Klasse, statt Interface als Typ gewählt.
- JavaDoc ist leer oder beschreibt nur triviales, insbesondere werden die Fehlerfälle (wann Exceptions geworfen werden) nicht erwähnt (Geerbte Methoden müssen kein JavaDoc haben)
- Sehr komplexe Codestelle fehlt ein erklärender Kommentar oder Komplexe Codestelle sollte eigentlich durch geeignete Hilfsmethoden strukturiert werden
- Verwendung von Wildcards bei Importanweisung
- Nicht den geeignetsten Schleifentyp gewählt, z.B. While statt For oder For statt ForEach
- Code enthält auskommentierte Quelltext-Schnipsel, TODOs, oder unangemessene Kommentare
- Exception werden für den Kontrollfluss benutzt
- Try/catch Blöcke sind sehr groß und umfassen nicht nur die nötigen Konstrukte
- IndexOutOfBoundsException oder NullPointerException fangen, statt Größe zuvor zu prüfen oder auf null zu prüfen