Skip to main content
Wachter Space 🚀
  1. Posts/

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