Regeln für die LV Programmieren in C++

Nutzung von KI:

Sie sollen in der LV selbständig Aufgabenstellungen abstrahieren und in kleinen Programmen selbständig umsetzen können.

• "... zuhören, abstrahieren und modellieren." [siehe Heise online]
• Sie können verfügbare Co-Piloten, Webseiten mit KI, etc. benutzen. Die ensprechenden Codepassagen sind eindeutig zu kennzeichnen. Eine Nichtkennzeichnung zählt als Betrugsversuch.
• Sie sind verantwortlich, falls die Aufgabenstellung von der KI nicht korrekt (oder nicht vollständig) gelöst wurde.
• Sie sind verantwortlich für die Testung des von der KI erzeugten Codes.
• Sie müssen den abgegebenen Code selbst verstehen und Dritten erklären können.

Style Guide:

Wir folgen im wesentlichen dem Google C++ Style Guide. Das daraus wesentliche für die LV ist hier zusammengefaßt.

Ein Ziel der LV besteht darin, daß die Studenten/-innen korrekt strukturiert und objektorientiert programmieren. Daher werden folgende Konstrukte bei der Lösungsabgabe sofort mit 0 Punkten sanktioniert:

• continue, goto und break (außer im switch-statement).
• Jede Funktion besitzt genau eine return-Anweisung am Ende der Funktion. Somit:
• kein return aus einem for/while/do-while-Zyklus heraus.
• kein return aus einer if/else/elseif/switch-Anweisung heraus.
• Ein for-Zyklus darf nur im klassischen Sinn verwendet werden, d.h., wenn die Anzahl der Zyklendurchläufe vor dem Start des ersten Zyklus' bekannt ist (Bsp.: Summation).
• Nehmen Sie keinen while/do-while-Zyklus, wenn ein for-Zyklus nach obigem Punkt besser passen würde.

Macros dürfen nicht definiert werden (z.B.:  #define r(v) cin >> v). Dafür sind Funktionen da.

Funktionen müssen klare Schnittstellen (Input/Output) besitzen:

• alle in einer Funktion benutzten Variablen müssen entweder in dieser deklariert werden oder in der Parameterliste aufgeführt werden.
• damit dürfen keine selbst deklarierten, globalen Variablen benutzt werden.

Ein weiteres Ziel der LV besteht darin, daß fehleranfällige Altlasten von C in C++ nichts verloren haben. Dies betrifft insbesondere Pointer.

• keine Benutzung von Pointern für statische oder dynamische Vektoren/Arrays (--> vector<>, array<>) oder andere, in der STL bereits enthaltene Datenstrukturen (list<>, set<>, map<>, stack<>, queue<>  etc.)
• keine Benutzung von Pointern zur Parameterübergabe (IN/OUT) an Funktionen (nur per value oder per reference)
• keine Benutzung von Pointern zum Zugriff auf Daten (außer es ist zu Übungszwecken explizit gefordert).
• Wir werden Funktionspointer und Basisklassenpointer an entsprechender Stelle erlauben, wobei functional und shared_ptr diesen vorzuziehen sind.

Programmieren Sie defensiv:

• Nutzung des Schlüsselwortes const wann immer möglich.
• Programmieren Sie so, daß Sie Ihren Code verstehen. Vermeiden Sie fehleranfälliges Zusammenziehen von Ausdrücken mit Nebeneffekten (++k vs. k++ in komplexen Ausdrücken)
• Benutzen Sie C++-Vektoren/Arrays (und allgemein Container) statt C-Arrays.
• Dokumentieren Sie Ihren Code mit doxygen.
• Schalten Sie die Compiler-Warnungen ein und gehen Sie deren Ursachen auf den Grund. Ihr Code sollte ohne Warnungen compilieren.
• Nutzen Sie assert() zur einfachen Überprüfung auf korrekte Inputdaten (evtl. auch bei Ihren Ergebnissen) bei Funktionen/Berechnungen/etc.
  Lieber ein sofortiger Programmabbruch als ein Weiterrechnen mit falschen Daten!
  Das Einbinden des Headerfiles nicht vergessen: #include <cassert> .
  Mit der Compileroption  -DNDEBUG kann die Überprüfung mitels assert() ohne Quelltextänderung ausgeschaltet werden.
• Wer mit LINUX/Mac arbeitet: Nutzen Sie die vorbereiteten Makefiles z.B. via
• make run
• make codecheck
• make codecheck COMPILER=CLANG_

--  will be continued --

January 7, 2026