gruppe06-hufflepuff-projekt.../Bewertung_TextEditor.md

137 lines
5.7 KiB
Markdown

# 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`