gruppe06-hufflepuff-projekt2-texteditor/Bewertung_TextEditor.md

Bewertung Text Editor

🥇 13 Punkte von 15

👫 brandleo@students.zhaw.ch; fassband@students.zhaw.ch; schrom01@students.zhaw.ch; zieglmic@students.zhaw.ch; amadoste@students.zhaw.ch

Allgemeine Anforderungen (all-or-nothing)

Voraussetzung für Punkterteilung: Die Applikation ist lauffähig.

Entwicklung

👨‍🏫 9.5 Punkte von 11

Funktionalität: 3.5 Punkte von 4

Vorführung oder Test durch Betreuer

• (ADD, DEL, REPLACE) Einfügen und Löschen ganzer Absätze; Globales Suchen und Ersetzen von Text innerhalb > eines Absatzes.
• (FORMAT RAW, PRINT) Unformatierte, absatzweise Ausgabe des Textes mit Angabe der Absatznummer
• (INDEX) Ausgabe eines Indexes (Wortverzeichnisses) aller Worte, die öfter als zweimal auftreten mit Angabe des Absatzes
• (FORMAT FIX, PRINT) Formatierte Ausgabe von Text mit einer einstellbaren maximalen Spaltenbreite Zeichen, Zeilenumbruch jeweils auf dem letzten Lehrzeichen
• Sonderzeichen werden gefiltert
• Fehlermeldungen auf System.err

• FORMAT RAW sollte das Standardverhalten sein.
• FORMAT FIX:
  • Wenn ein Wort länger ist als die Breite sollte es im Wort umgebrochen werden.
  • Es bricht um wenn der Text >= columnWidth ist. Die Idee ist es nach der Spaltenbreite umgebrochen wird (Leerzeichen zählt nicht dazu)

CleanCode und Konstrukte: 1.5 Punkte von 2

Sie halten die Vorgaben hinsichtlich einsetzbarer Konstrukte und Clean Code ein, und Ihr Code ist sauber dokumentiert. (Kriterium: Codeanalyse durch Betreuer, ggf. Erläuterung)

• Der TextLogic Konstruktor macht viel zu viel
  • Ein Konstruktor sollte nur das Objekt einrichten/vorbereiten
  • Besser: TextLogic textLogic = new TextLogic(); textLogic.run();
  • Zudem ist er zu lange. Es würde sich lohnen mehrere Funktionen daraus zu machen (z.B. jeder Befehl seine eigene Funktion)
• Text.createWordList sollte nicht eine leere Map als Parameter übernehmen, sondern die Map selbst erstellen und zurückgeben.
• Text.addund TextOutput.formatRaw geben immer true zurück. Rückgabewert kann weggelassen werden.
• Tipp: Beachten Sie die Meldungen von IntelliJ. Sie können auch das ganze Projekt überprüfen lassen (Code -> Inspect Code)

Klassendesign: 2.5 Punkte von 3

Sie haben eine sinnvolle Aufteilung in Klassen und Klassendefinitionen gefunden. (Dokumentation der Klassenhierarchie ist mit hochzuladen. Kriterium: Analyse durch Betreuer, ggf. Erläuterung)

• Gute Aufteilung der Klassen und deren Aufgabenbereiche
• Die Pfeile zeigen in die falsche Richtung. Ein Assoziationspfeil (A -> B) bedeutet: A verwendet B
• Hinweis:
  • Es macht es etwas übersichtlicher, wenn unterschiedliche Pfeile sich nicht überschneiden

Test: 2 Punkte von 2

Sie haben sinnvolle Test Cases für die Funktion Index definiert, diese in JUnit umgesetzt und erfolgreich ausgeführt.

• Sehr gute Auswahl von Tests
• Hinweise
  • Ein BeforeEach ist nicht immer nötig
    • Nachteil von BeforeEach: Es macht die Tests unübersichtlicher; es genügt nicht die Test-Funktion anzusehen
    • Nützlich wenn das Erstellen des Anfangszustandes komplex ist, nicht aber wenn es nur ganz einfache Konstruktoren sind; Besonders auch wenn es nicht in allen Test-Funktionen verwendet wird (stringListe)
  • Nur bestimmte Werte einer Liste zu prüfen ist nicht zuverlässig. Es könnte z.B. zu viele Einträge haben. Beispiel:

Assertions.assertEquals("Word    1, 2", stringListe.get(0));
Assertions.assertEquals("Test    1, 2, 3", stringListe.get(1));

// more precise:
Assertions.assertEquals(List.of("Word    1, 2", "Test    1, 2, 3"), stringListe);

• Tests können verschachtelt/gruppiert werden:

class TextTest {
  @BeforeEach
  void makeTestLists() {
    // ...
  }

  @Nested
  class IndexTest {
    @Test
    void emptyTest() {
      // ...
    }
  }
}

• Gedanken-Experiment: Wie würden Sie jetzt wo Sie Vererbung kennen die Konsolen-Ausgabe testen?

Vorgehen und Dokumentation

👨‍🏫 3.5 Punkte von 4

Dokumentation: 2.5 Punkte von 3

• Ihr Code ist in Javadoc (mindestens für Klassen und Public Methods und zusätzlich für Konstruktoren, jedoch generell ohne Getter/Setter) und wo sinnvoll in Zeilenkommentaren zur Funktionalität dokumentiert.
• Klassendiagramm ist auf GitHub abgelegt.
• Relevante Informationen finden sich im README.

• @Class und @Constructor Tags gibt es nicht. Dies verwirrt Generatoren von Dokumentationen. Z.B. IntelliJ zeigt diese auch nicht an.
• Verwenden Sie Tags für z.B. Autoren: @author
  • Dies ermöglicht bessere Anzeige
• Hinweis
  • Das Datum würde ich nicht in die Dokumentation schreiben
    • Das sind redundante Informationen, welche bereits in git vorhanden sind
    • Es ist schnell passiert, dass es vergessen wird anzupassen und schlechter als keine Dokumentation ist eine falsche Dokumentation

Beitrag: 1 Punkt von 1

Alle Gruppenmitglieder haben gleichermassen Code beigetragen und auf GitHub eingechecked. (Eine einfache Variante wäre, dass jedes Gruppenmitglied für bestimmte Klassen verantwortlich ist, andere Aufteilungen sind aber denkbar. Kriterium: Check durch GitHub Log, Dokumentation im Code.)

• Alle haben gleichmässig beigetragen

Zusätzliche Hinweise (nicht bewertet)

• Guard-Clauses können auch in Loops verwendet werden (Beispiel Text.createWordList):

// without
for (String word : words) {
  if (word.length() > 0) {
    // complex implementation
  }
}
// with guard-clauses
for (String word : words) {
  if (word.length() == 0) {
    continue;
  }
  // complex implementation
}

• Es sollte nicht im Default-Namespace gearbeitet werden
  • Dies erschwert die Verwendung aus einem anderen Program
  • Der Code ist nicht klar verpackt
  • Gängig: wie eine umgekehrte Domain. Z.B. ch.zhaw.text_editor