# 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.add`und `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:

```java
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:

```java
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`):
```java
// 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`