Maxime für SP1

(Noch im Aufbau)

Speicher erst beschreiben, dann lesen.

In der Regel gibt der C Standard einer Implementierung (Compiler, Interpreter, ...) nicht vor wie der Inhalt einer neuen Speicher-Objekts auszusehen hat. Außer es ist explizit bekannt (calloc) ist es also sicherer anzunehmen, dass der Inhalt nicht definiert ist. Es hängt also von dem jeweiligem System ab, was konkret der Speicherinhalt sein wird. Fließt diese Tatsache, in das Verhalten eines Programms ein, sagt man es verlässt sich auf undefined behaviour, was per Definition nicht portabel ist.

Eine Commit Nachricht beschreibt was geändert wurde, nicht was.

Die Absicht eines SCM bzw. VCS ist es idealerweise konsistente Kontrollpunkte eines Projekts aufzufassen. Wenn man zurückschaut, will man mit jeder Revision einen Übergang von einem Zustand zu einem anderem erkennen können. Was sich zwischen diesen geändert hat, kann man mit git diff bereits sehen (hier ist auch das Ideal die Änderungen selbst möglichst klein und spezialisiert zu halten). Die Commit-Nachricht selbst braucht das nicht wiedergeben: Genau wie bei Kommentaren im Quelltext, kann man annehmen der Leser versteht die Sprache — es ist nicht deine Aufgabe diesem C beizubringen. Stattdessen liegt die Unklarheit meistens darin, wieso etwas geändert (oder in der Quelltext-Analogie geschrieben) wurde. Das zu erklären ist was den Leser wahrscheinlich eher interessieren wird. Hier kann man noch qualifizieren, indem man zwischen dem Commit Header und dem Commit Body unterscheidet. Ersteres kann noch deskriptiv sein, weil man das benutzt um in einer Liste (git log --online) zu suchen, während die Commit Body meist neben dem Diff steht, und somit keinen Grund hat dieses zu duplizieren.