Stefan Röttger

●

Generell:

• Erst denken, dann tippen! Andersherum hilft nicht!
• Raten hilft ebenfalls nicht!
• Es hilft hingegen sehr, die Dokumentation bzw. das Skript vorher zu lesen!
• Machen Sie niemals zu viele Schritte auf einmal → Salami-Taktik!
• Wenn Sie eine Salamischeibe abgearbeitet haben, testen Sie Ihr Programm.
• Es wird in vielen Fällen schon nicht mehr funktionieren.
• Beheben Sie dann zuerst den Fehler, bevor die nächste Salamischeibe dran ist.

Teamwork:

• Sie sollten niemals gleichzeitig am selben Modul arbeiten!
• Sie sollten Sich daher absprechen, wer an welchem Modul exklusiv arbeitet.
• Ein Abgleich der Änderungen untereinander erfolgt erst nach einem erfolgreichen Test.

2er-Teams:

• Anfangs:
  • Für den Anfang empfehle ich, dass Sie nur mit einer einzigen Kopie arbeiten.
  • D.h. man trifft sich im Praktikum und jeweils einer arbeitet und der andere schaut zu und gibt Hilfestellung!
  • Dann wird nach einer gewissen Zeit der Rechner weitergereicht und die Rollen kehren sich um.
  • Sie können natürlich auch über Discord zusammen arbeiten und nach der Session sich den jeweils aktuelle Code zukommen lassen.
• Später:
  • Später kann jeder seine eigene Kopie haben, mit der man parallel entwickeln kann.
  • Aber auch dann sollten Sie zusammen und nicht getrennt programmieren.
    • So können Sie Sich z.B. auf Discord verabreden, um untereinander absprechen zu können, wer gerade an welchem Modul arbeitet, und welche Änderungen der jeweils andere Programmierpartner benötigt.
    • Der Austausch der Änderungen kann dann z.B. über die Drop-Box erfolgen.
• Machen Sie in jedem Fall regelmässig Sicherheitskopien Ihres aktuellen Entwicklungsstands
  • Jede Sicherheitskopie Ihres Programmordners sollte einheitliche aufsteigende Versionnummern tragen, also z.B. MyGame-V0001, MyGame-V0002, …
  • Wenn Sie einen Abgleich benötigen, dann bietet es sich an, eine solche Sicherheitskopie hochzuladen, mit der der jeweils andere Programmierpartner dann seine Version aktualisieren kann. Woraufhin dieser nach seinen Änderungen wiederum eine solche Sicherheitskopie anlegt - und so fort …
  • Dieses Prozedere baut letztendlich manuell die Abgleichs-Funktion einer Versionverwaltung nach - sozusagen Versionsverwaltung für Arme. Man könnte natürlich jetzt gleich eine richtige Versionsverwaltungssoftware einsetzen, aber hier warten jede Menge ungeahnte Fallstricke. Das wäre eine eigene Vorlesung → PROG3/A!
• Rule of Thumb:
  • Für jeden Tag, an dem Sie an Ihrem Spiel gearbeitet haben, machen Sie mindestens eine Sicherheitskopie, damit Sie diese mit Ihren Programmierpartnern abgleichen können und anderntags damit weiterarbeiten können. Jede solche Kopie sollte getestet werden, ob sie auch wirklich compiliert.
  • Und wenn man sich einmal verrannt hat, kann man ja jederzeit zu einer früheren Version zurückkehren.

Größere Teams:

• Empfohlen ist ein Educational Account auf github.
• Dort legt man ein leeres Repository an mit der dazugehörigen URL (mit der Endung .git).
• Auschecken: git clone URL.git
• Nun kopieren Sie Ihren Quellcode etc. in das lokale Repository hinein.
  • Ins git Repository gehören nur die Quellcode Dateien, das CMakeLists.txt und eventuell ein README.txt
  • D.h. keine überflüssigen oder temporär erzeugten Dateien wie CMakeCache.txt!!!
  • Auch keine Binaries
  • Nur *.h *.cpp *.txt
• Damit ist der tägliche Abgleich der Versionen untereinander wie folgt:
  • Morgens:
    • git pull
  • Abends:
    • git diff (ob die Änderungen passen, evtl. muss man noch Programmiermüll entfernen)
    • git add *.h *.cpp *.txt (kürzer: git add -A, aber Vorsicht mit überflüssigen Dateien!!!)
    • git commit -m “commit log = Kurzbeschreibung der Änderungen” (Erstellen einer neuen lokalen Version)
    • git push (Hochladen der lokalen Version auf github)
• Es ist guter Usus in der Programmierpraxis mindestens einmal täglich einzuchecken!
  • Am besten bereits, wenn man einen Programmierschritt fertiggestellt hat (z.B. eine neue Funktion, eine Verbesserung, oder einen Bug-Fix)
• Checken Sie niemals ein ungetestetes Programm ein!
• Checken Sie insbesondere niemals ein Programm ein, das sich nicht übersetzen lässt!
  • Sonst bekommen Sie unweigerlich Ärger mit Ihren Teamkollegen ;-)
  • Aber wenn man sich derart verrannt hat, kann man ja jederzeit zu einer früheren Version zurück kehren - z.B. mittels git reset HEAD@{1}, aber das ist nun wirklich etwas für Routinierte. Lassen Sie Sich hier bitte lieber im Praktikum helfen, als dass Sie Ihr Repository noch weiter kaputt machen. Das kann ganz schnell passieren. Bzw. dies wird sonst sehr bald passieren!
• Wie eigentlich überall beim Programmieren gilt daher insbesondere für git: Erst denken, dann tippen!

Build Setup:

• Es ist in jedem Fall ein sog. Out-of-Source Build empfohlen!
• Darunter versteht man, dass die binären Objekt- bzw. Build-Dateien in einem anderen Verzeichnis als der Quell-Code abgelegt werden.
  • QtCreator erstellt automatisch die Build-Dateinen “out-of-source”, d.h. nicht im Source-Verzeichnis sondern eine Dateiebene darunter
  • Wenn man jedoch auf der Kommandozeile arbeitet (cmake . && make), dann muss man sich selber darum kümmern:
    • Leeres “build”-Verzeichnis anlegen
    • In dieses Verzeichnis wechseln mit cd
      • nun nicht “cmake .” tippen
      • sondern “cmake <Pfad zum CMakeLists.txt>”
      • make
  • Dadurch liegen alle tempöraren Build-Dateien in einem separaten Verzeichnis “build”!

Nettiquette:

• Eine Zeile = eine Anweisung
• Der Code sollte konsistent eingerückt werden
  • Nach jedem { → 4 Leerzeichen einrücken
  • Vor jedem } → 4 Leerzeichen ausrücken
• Funktionen sollten vor der Implementierung mindestens eine vorhergehende Kommentarzeile erhalten
• Größere zusammenhängende und/oder logisch separierbare Code-Squenzen werden durch Leerzeilen getrennt und erhalten ebenfalls einen vorhergehenden Kommentar
• Anmerkungen zur Funktionsweise können mit // hinter der betreffenden Zeile angefügt werden
• Code kann man auskommentieren, besser ist #if 0 … #else … #endif

Einrückungsbeispiel:

●