SE-Tutorium 4 | Mittwoch 16 - 18 Uhr:

anchored to [[191.00_anchor]]

Lernziele:

  • Probleme der vorherigen Hausaufgabe durchgehen?
  • IDE gut nutzen können
    • Ein Repository mit großer Codebase einsehen und verstehen
  • Dokumentation lesen, verstehen und anwenden können
  • Dokumentationen selbst schreiben können
  • Style Guides
    • was sind sie
    • wie nutzen wir sie
    • warum?

Ziele der Stunde:

  • Hausaufgaben erinnerung
  • Mit der IDE arbeiten können ( am Beispiel des Hexacraft-Repos)
  • Gründe für Documentation?
    • Warum ist Documentation wichtig?
  • Documentation von Scala anschauen und betrachten
  • Style Guides wiederholen
  • Style guides betrachten ( Beispiel Scala)
  • Benennung von Variablen / etc

Orga |

  • Konnte leider noch nicht HW3 korrigieren, ( Denke bis Freitag fertig)

  • Probleme mit den letzten Korrekturen?

  • Ich hab jetzt Süßigkeiten mit!

  • Wir werden weiterhin im Raum D4A19 bleiben

  • Raum war wohl schon seit Beginn des Semester vorgesehen, wurde falsch kommuniziert

note: ask them about the last corrections –> maybe go around and ask at a later point

Orga | Hausaufgabe:

  • Wichtig, die neuste Hausaufgabe ist verfügbar HW5!
  • macht euch frühzeitig Teams!
    • wenn noch keins gefunden, hier im Tutorium fragen!
  • Am besten dafür in Person mit dem Team treffen

note: give them 5 min to find a group maybe, in case they have not

\Inhalte dieses Tutorium\

  • IDE Features nutzen und probieren
  • Dokumentationen lesen und verstehen können
  • Dokumentation selbst schreiben
  • Style Guides als Konzept
  • Betrachtung diverser Style Guides, Verwendung dieser
  • Naming von Variablen und weiteren Konstrukten

| Probleme bei HW3 |

  • Listet gerne auf, wo bei Hausaufgabe 3 Probleme aufgetreten sind, und warum

[!Aufgabe] Diskutiert die Fragen in in kleinen Gruppen:

  1. Wie fandet ihr die Hausaufgabe ( schwer, leicht, spannend,…)?

  2. Wo gab es Schwierigkeiten / wo kamen Probleme auf?

  3. Haben Tools, wie AI-Assistance hier geholfen? Wenn, warum, warum nicht?

  4. Was waren Probleme die bei der Arbeit mit einer größeren Codebase auftraten?

  5. Welche Probleme treten generell auf, wenn man im Team arbeiten muss?

note: give them ~ 10 min to discuss those

| Hausaufgabe 5 |

  • Schaut euch die Aufgabe für etwa 5 minuten an, um sie grundlegend verstehen zu können
  • Gibt es Fragen zum Verständnis?
    • i.e. Was müssen wir dann erreichen?

IDE Features:

  • IDEs haben Features für Dinge, wie “Refactoring”, “Renaming” etc
  • viele Tooltips, Empfehlungen, Features für einfacheres Coden

[!Task] Aufgabe, IDE Features verstehen

  1. Finde Usage, von Klasse “Renderer” in folgendem Pfad:

    • src/main/scala/com/martomate/hexacraft/renderer/Renderer.scala

  2. “Refactor” einen Teil aus der Methode logThrowable zu finden in:

    • src/main/scala/com/martomate/hexacraft/main/Main.scala

  3. Find einen besseren Namen für BlockFactory in folgendem Pfad:

    • src/main/scala/com/martomate/hexacraft/world/block/BlockFactory.scala

note: give them 10-15 min?

Documentation \a love letter to future you\

  • Mit Dokumentationen möchten wir Code dokumentieren

    • Fähigkeiten erklären
    • Prinzipien auflisten, definieren
    • Verständnis / Konzepte schaffen
    • Beispiele geben etc

  • Dokumentationen helfen nicht nur beim Code / Software-Design

    • Übersicht über Struktur geben
    • Verständnis von einzelnen, spezifischen Einzelheiten einsehen können
    • als neues Mitglied verstehen, wie der Zustand ist

Documentation | wichtig!

  • (auch in der Vorlesung besprochen):
  • Dokumentationen treten auf verschiedenen Ebenen auf.
  • extern
    • Wikis, Docu-Websites,
    • Contracts, Ausgearbeitete Anforderungen
    • Posts oder Einträge zur Architektur selbst
  • intern | Source code selbst
    • Kommentare ( nicht immer supi )
    • Benennungen von Inhalten, Variablen, Methoden etc

note: maybe bad example from my teamproject! https://github.com/nicolasseng/teamproject-objectdetection/blob/main/modules/moduleDetectionMobileNetSSD.py Warum ist es schlecht / nicht gut?

Documentation | Verstehen | Nutzen

  • wollen uns folgend diverse Dokumentation-Beispiele anschauen
  • großer Vorteil bei Scala –> Docs können generiert werden

[!Task] Aufgaben zur Arbeit mit einer Dokumentation

note: 5 - 10 min? maybe interactively

Documentation | Verstehen | Nutzen

  • Beispiel-Dokumenation betrachtet –> wir wollen selbst welche schreiben!
  • Daher folgende Aufgabe ausarbeiten

[!Task] Aufgabe Schreibt eine kleine Dokumentation zu einem undefinierten Teil in dem Repository hier!

Können wir sie uns dann in der IDE anzeigen lassen? warum?

Führe sbt doc aus, und suche nach deiner Dokumentation in dem Project

| Style Guides |

  • lesbarer Code ist Key für die Entwicklung von Software!
  • hilft Fremden den Code zu verstehen und damit zu arbeiten
  • wir verstehen ihn auch!
    • wir wissen, was abgeht
  • Style-Guides als Konvention, die festlegt, wie Code geschrieben und formatiert werden sollte.

| Style Guides |

  • Style-Guides umfassen viele Inhalte
    • Schreibweisen von Definitionen ( PascalCase, camelCase, snake_case …)
    • präferierte Wörter zur Benennung ( off by one / cache invalidation)
    • Indentation
    • Klammer-Position
    • Argumente und ihre Struktur
    • etc…
  • Cool, aber muss man erstmal einhalten

| Style Guides |

  • Always try to automate
    • Styling-Convention kann man vergessen oder aus Versehen nicht einbringen
    • automatisch die Konvention einhalten lassen!

![[Pasted image 20231122012937.png]]

| Style Guides | anschauen:

  • Scala hat auch einen StyleGuide für die Sprache
  • wir wollen sie uns ferner anschauen
  • https://docs.scala-lang.org/style/indentation.html

[!Task] Aufgabe Schaut euch in einer kleinen Gruppe den Scala-Style-Guide an

  1. Wie findet ihr manche Conventionen? Können wir sie verbessern / ändern?
  2. Warum brauchen wir StyleGuides? Ist der für Scala sinnvoll?

note: discuss it shortly with the others

| Style Guides | forcieren | verändern

  • Scala hat tool scalafmt, um Code entsprechend formatieren zu können
  • hilft Code zu schreiben der dem Style-Guide entspricht –> Lesbarkeit!
  • Möglichkeit des Checkens der Formatierung und Korrektur dieser möglich!
    • check sbt scalafmtCheck
    • format sbt pathToProject/scalafmt
  • oder auch beim Hochladen / pushen auf ein REPO möglich
    • –> enforce Style-Guide des Repository!

| Style Guides | üben und im Repository Dokumentation hinzufügen!

[!Task] Aufgabe

  1. Suche dir im Repository etwas was dokumentiert werden sollte
  2. schreibe ein issue dafür und gib an, warum es dokumentiert werden muss
  3. nimm ein Issue und bearbeite es. ( Also Code finden, dokumentation sinnvoll! schreiben)
  4. erstelle einen Branch Issue/X und füge deine Änderung hinzu
  5. formatiere nach Style-Guide!
  6. review push von anderen!

Feedback:

  • Hausaufgaben 4 / 5 nicht vergessen
  • Teams für die Abgaben gründen!
  • Gerne das untere Forms ausfüllen :)

Feedback HW03:

12 people attended this tutorial //

Ein schritt erledigen und man musste dann warten

  • vielleicht explizite Deadlines für kleinere Aufgabenteile setzen
  • Also angeben, dass man die Issue etwas bis zu einem Datum erfüllt haben muss

[!Question] How to validate that students did those tasks until then?

They asked whether one could

Tell them on how to repaire IntellIJ if something breaks / does not work

for HW5

  • they have the opportunity to design the software as they wish
  • manye implementations possible –>

IO-complexity