TODOs, Regionen und andere Altlasten

Zwei Sonderformen verdienen eine eigene Betrachtung, weil sie sich in fast jedem gewachsenen Projekt finden — und weil beide gut gemeint anfangen.

Der TODO-Friedhof

Ein // TODO ist ein Versprechen an die Zukunft. In den meisten Projekten ist es ein gebrochenes:

// TODO: Fehlerbehandlung verbessern
// TODO: refactoren
// HACK: geht auch schöner
// FIXME: funktioniert nicht bei Schaltjahren

Nach zwei Jahren stehen dreihundert davon im Projekt. Niemand liest sie, niemand löscht sie, und ein tatsächlich wichtiger Hinweis geht darin unter.

Das Problem ist nicht das TODO selbst, sondern dass es keinen Empfänger hat. Ein brauchbares TODO nennt drei Dinge — was, warum, und wo es nachverfolgt wird:

// TODO: refactoren

// TODO(SHOP-1487): Auf die
// Batch-Schnittstelle umstellen,
// sobald der Anbieter sie
// freigeschaltet hat — einzeln
// dauert der Nachtlauf 40 min.

#region

#region faltet Codeblöcke in der IDE zusammen. Das klingt nach Ordnung und ist meistens das Gegenteil:

public class KundenService
{
    #region Felder
    …
    #endregion

    #region Öffentliche Methoden
    …          // 600 Zeilen, eingeklappt
    #endregion

    #region Private Hilfsmethoden
    …
    #endregion
}

Eingeklappt sieht die Klasse aufgeräumt aus. Ausgeklappt sind es tausend Zeilen. Die Region hat nichts geordnet — sie hat das Problem unsichtbar gemacht, und zwar genau für die Person, die es sonst bemerkt hätte.

Regionen, die nach Sichtbarkeit gruppieren (Felder, Eigenschaften, Methoden), liefern ausserdem keine Information: Das sieht man den Elementen an. Wenn eine Klasse Regionen braucht, um überschaubar zu bleiben, ist sie zu gross — und der Ausweg heisst nicht Falten, sondern Teilen.

Was übrig bleibt

Als Faustregel für den Alltag:

Die kurze Fassung: Ein Kommentar, der etwas sagt, was der Code sagen könnte, ist ein Fehler. Ein Kommentar, der etwas sagt, was der Code nicht sagen kann, ist wertvoll.