TODOs sind eigentlich nicht zum Abarbeiten da

• Manche Teams haben Richtlinien, nach denen alle TODO-Kommentare im Bug-Tracker erfasst oder TODOs, die älter als ein Jahr sind, automatisch gelöscht werden, aber diese Praxis ist nicht zu empfehlen
• TODO-Kommentare sind nicht nur dann wertvoll, wenn sie zwingend erledigt werden müssen, sondern dienen als Schnappschuss des Denkens, der den Kontext und die Ideen zum Zeitpunkt des Schreibens festhält
• Wichtige TODOs sollte man zwar als Issue verwalten, die meisten sind jedoch Notizen mit niedriger Priorität oder Hinweise auf Edge Cases
• Ein gut platzierter TODO gibt künftigen Leserinnen und Lesern des Codes einen Hinweis auf die Absicht der damaligen Autorin oder des damaligen Autors, wenn sie überlegen: „Kann ich diesen Teil refactoren?“
• Der Wert eines TODO liegt nicht darin, ob es abgearbeitet wird, sondern darin, Kontext, Absicht und Möglichkeiten festzuhalten und so zukünftige Wartung und Zusammenarbeit zu unterstützen

---

TODO-Kommentare: Müssen sie wirklich abgearbeitet werden?

• In manchen Organisationen gilt die Regel, alle TODOs im Code in einem Bug-Tracker zu registrieren oder sie nach einer bestimmten Zeitspanne (mehr als ein Jahr) automatisch zu löschen
• Dieser Ansatz ist jedoch in der Praxis ineffizient und verfehlt das eigentliche Wesen von TODOs – ihr Wert entsteht nicht erst dadurch, dass sie tatsächlich bearbeitet werden

Der eigentliche Wert von TODOs

• Zum Beispiel kann ein Kommentar wie

  // TODO: 다음 주 출시 전에 이 파일의 뒷부분을 완성해야 함  
  

  durchaus etwas sein, das tatsächlich nachverfolgt werden sollte

• Gute TODOs sehen aber meist eher so aus:

  // TODO: 사용자가 이 버튼을 트리플 클릭할 경우, 핸들러에서 \[xyz] 오류 발생  
  

  und dienen dazu, Edge Cases zu dokumentieren oder Ideen für strukturelle Verbesserungen, die man gerade nicht umsetzen konnte, übersehene Situationen und Ähnliches mitsamt ihrem Kontext festzuhalten

TODOs sind kein „Plan“, sondern ein „Kanal“

• Die meisten TODOs haben tatsächlich eine niedrige Priorität und müssen nicht sofort bearbeitet werden
• Sie dienen dazu, die Überlegungen, Entscheidungen und den Kontext der Autorin oder des Autors zum Zeitpunkt des Schreibens an zukünftige Leserinnen und Leser des Codes weiterzugeben
• Wenn später jemand den Code liest und sich fragt: „Kann ich die Struktur hier ändern?“, hilft ein TODO dabei, die damalige Absicht zu verstehen

Die Wirkung gut geschriebener TODOs

• TODOs im Code liefern manchmal wichtige Hinweise auf mögliche Probleme, Chancen für strukturelle Verbesserungen oder unbehandelte Edge Cases
• Auch wenn sie nicht zwingend ein Umsetzungsplan sind, spielen sie für Zusammenarbeit und Wartung eine große Rolle bei der Vermittlung feiner Kontextinformationen
• Letztlich sind TODO-Kommentare wertvolle Aufzeichnungen, die das Verständnis des Codes und seine spätere Wartbarkeit erhöhen

Fazit

• TODOs sind nicht nur dann wertvoll, wenn sie abgeschlossen werden, sondern dienen als Kommunikationskanal, der die Gedanken, Absichten und den Kontext der Autorin oder des Autors festhält und an zukünftige Leserinnen und Leser des Codes weitergibt

[GN⁺]

Hacker-News-Kommentare

• Ich vertrete die Position: „TODOs sollten immer mit einem konkreten Issue verknüpft sein.“
  Ich denke, es gibt drei Wege, ein TODO vor dem Merge aufzulösen.
  1. Ein Issue anlegen — wenn es wirklich erledigt werden muss, lohnt es sich, etwa 20 Sekunden zu investieren, es zu dokumentieren und zu tracken.
  2. Es einfach direkt erledigen — wenn es zu klein ist, um daraus ein Issue zu machen, dann vor dem Commit beheben.
  3. In einen Kommentar umwandeln — wenn es nicht wichtig genug ist, um es zu beheben oder zu tracken, man sich aber daran erinnern möchte, sollte man es als normalen Code-Kommentar hinterlassen.
  Wenn einem die Gesundheit wichtig ist, sollte man sich TODOs anzugewöhnen wie Brokkoli zu essen: also sie zu tracken.
  • Das Tracking in einem externen System bedeutet nicht nur, ein Issue zu erstellen, sondern laufenden Zusatzaufwand wie Kategorisierung, Backlog-Verwaltung, Umklassifizierung und Schließen bei Abschluss.
    Issues in externen Systemen sind für Entwickler, die an genau diesem Code arbeiten, womöglich nicht gut sichtbar.
    Wenn selbst kleine, leicht behebbare Dinge zu tracken zu teuer ist, ist es effizienter, sie einfach als TODO stehen zu lassen.
    TODOs im Code fallen bei der Arbeit an diesem Code sofort ins Auge und lassen sich beim Refactoring leicht entfernen.
  • Der Autor des Beitrags scheint im Kern Variante 3 zu unterstützen, also es einfach als Kommentar zu belassen.
    Schade ist allerdings, dass der Unterschied zwischen einem TODO-Kommentar und einem normalen Kommentar nicht klar benannt wird.
    Der Begriff TODO selbst hat eine starke visuelle Signalwirkung, sodass sofort klar ist, um was für eine Art Kommentar es sich handelt.
    Die Behauptung, man müsse TODO-Kommentare nicht unbedingt als „TO DO“ verstehen, erscheint mir etwas fragwürdig.
    Dem Grundgedanken des Artikels stimme ich weitgehend zu, aber eine Verbesserung wäre aus meiner Sicht eher, einfach normale Kommentare zu verwenden.
  • Es hieß, man müsse nur „20 Sekunden investieren, um es festzuhalten und zu verwalten“, aber genau das ist doch bereits ein TODO.
    In ein Ticketsystem eingetragen dauert es nicht nur länger als 20 Sekunden, sondern erzeugt eher Ablenkung, statt zu helfen.
  • Tracking in 20 Sekunden wäre schön, aber bei uns im Großunternehmen hat ein einzelnes JIRA-Ticket mehr als zehn Pflichtfelder.
  • Ich habe nur eine Regel: Jedes TODO muss eine Ticketnummer enthalten.
    // TODO: improve the routing https://jira.com/whatever/TIX-1234
    Der Grund ist, dass Kommentare sonst zu Waisen werden und niemand mehr weiß, warum sie hinterlassen wurden.
    Lässt man nur einen Kommentar stehen, vergisst später jemand Zweck und Hintergrund.
    Deshalb sollte man entweder unbedingt ein Ticket anlegen oder es sofort erledigen.
• Ich grepe sie folgendermaßen getrennt.
  FIXME: eindeutig falsch oder kaputt, höchste Priorität
  XXX: unschön oder auf einer falschen Annahme basierend, hohe Priorität
  TODO: etwas, bei dem irgendwann ein völlig neuer Ansatz/eine neue Kategorie/ein neuer Zweig implementiert werden muss
  NOTE: zur Vermittlung von Informationen, die wichtiger sind als ein einfacher Kommentar
  Ich arbeite meist an Legacy- oder nicht gewarteten Code-Engines; dort gilt „der Code ist die Wahrheit“, daher erstelle ich kein JIRA, sondern korrigiere Dinge direkt beim Lesen.
  • Ich verwende es so.
    TODO: etwas, das vor dem Release zwingend nötig ist, ein Muss. Wenn das nicht zutrifft, sollte es in eine andere Kategorie verschoben werden. Es blockiert das Release.
    FUTURE: könnte irgendwann ein TODO werden, meist optionale Dinge wie strukturelles Design
    MAYDO: wäre nett, ist aber nicht nötig
    PERF: sinnvoll, wenn mehr Performance gebraucht wird
    Außerdem verwende ich semantische Tags aus dem jeweiligen Fachbereich.
    Meiner Meinung nach ist TODO kein Code Smell, sondern etwas, das sich ganz natürlich in den zentralen Teilen einer Codebasis ansammelt.
  • Ich nutze XXX als persönliche Notiz im Sinn von „muss vor dem nächsten PR unbedingt behoben werden“.
    Wenn ich es ernst meine, konfiguriere ich CI so, dass Code mit diesem String abgelehnt wird.
    In diesem Sinn hat XXX für mich die höchste Priorität.
  • Diesen Stil mag ich. In einem Projekt hatten wir CI so eingerichtet, dass Code mit FIXME immer abgelehnt wurde und TODO nur mit vorhandenem Issue-Ticket akzeptiert wurde.
    Nach Priorität abgestuft hieß das:
    FIXME: um den Fokus zu halten. Muss gelöst werden, bevor gemergt werden kann oder der Code fertig ist.
    XXX: sollte bald behoben werden. Funktioniert im Moment, muss aber zeitnah korrigiert werden.
    TODO: später noch einmal ansehen. Der Code ist vollständig benutzbar. Niedrigere Priorität als XXX.
    NOTE: erklärt Besonderheiten oder Wissenswertes und hilft so späteren Bearbeitern.
  • Ich mache es ähnlich. Bei noch unvollständigen, aber umgehbaren Codepfaden setze ich statt FIXME ein assert.
    TODO nutze ich, um mögliche Arbeiten wie Refactoring, Performance- oder Verständlichkeitsverbesserungen zu notieren.
    NOTE verwende ich, um historischen Kontext oder Gedankengänge festzuhalten, die man nicht sofort erkennt.
  • In der Theorie gut, aber ohne Tool-Unterstützung sind solche Konventionen meiner Meinung nach bedeutungslos.
    Erst recht, wenn man im Team arbeitet.
    Das heißt aber nicht, dass sie grundsätzlich sinnlos wären — eher, dass es solche Tools geben sollte oder gebaut werden müsste.
• Mir fällt der Satz ein: Das Perfekte ist der Feind des Guten.
  Solche technische Schulden oder Code Smells sollte man eigentlich besser verfolgen, dokumentieren und erklären, aber sobald man stattdessen zu produktivitätshemmenden Dingen wie JIRA greifen soll, dokumentiert man am Ende lieber gar nichts mehr.
  Wenigstens bleibt mit einem TODO im Code überhaupt etwas erhalten.
  TODOs sind schließlich tatsächlich „zu erledigende Dinge“, also haben sie Bedeutung.
  • In großen Codebasen können die TODOs vieler Leute natürlich ineinanderlaufen und unübersichtlich werden, aber für persönliche Projekte ist das ein guter Kompromiss.
    „Ich weiß, dass man das besser machen könnte, aber ich unterbreche meinen Flow dafür bewusst nicht. Die Funktion ist nicht kaputt, es wäre nur ein kleines Plus.“
    Wenn im Editor die TODO-Hervorhebung gelegentlich wieder auftaucht, hilft das, wenn man gerade kurz etwas erledigen möchte.
    Trotzdem bleiben die meisten TODOs dort lebenslang stehen oder werden in der Praxis fast nie gelöst.
  • Manchmal hinterlasse ich TODOs einfach, weil ich im Code ein Signal für etwas setzen will, das behandelt werden sollte.
    Selbst wenn man es in JIRA, GH Issues usw. einträgt, muss der Eintrag letztlich doch mit dem Code verknüpft sein.
    Und wenn man nur eine Referenz stehen lässt, kann deren Bedeutung später verloren gehen; deshalb sollte im Kommentar auch eine Erklärung stehen.
  • Es gibt bereits eine Funktion, mit der ein MCP-Server JIRA-Tickets per AI erstellt und direkt aus Cursor ausgeführt werden kann.
  • Ich halte es für viel besser, so etwas in Git-Commit-Messages festzuhalten.
    Viele Commits transportieren den Inhalt in Wirklichkeit nicht gut.
    Statt die alte Gewohnheit von TODOs zu fördern, sollte man besser zur Nutzung besserer Werkzeuge anregen.
    Viele Entwickler committen viel zu selten und packen dann mehrere Arbeiten auf einmal hinein.
    Auch Commit-Messages sind oft inhaltsleer, etwa „updating somefile.py“.
• Das ist eine Stilfrage. Für TODO gibt es je nach Person unterschiedliche Definitionen und Kultur.
  In meiner Codebasis wird TODO genau so verwendet, wie es hier beschrieben ist.
  TODO dient dazu, die Implementierung zu erläutern, insbesondere fehlende Teile zu dokumentieren — nicht unbedingt im Sinn von „muss erledigt werden“.
  Ich halte es nicht für besonders sinnvoll, eine echte Aufgabenliste im Code selbst zu hinterlassen. Prioritäten ändern sich ständig; etwas konnte beim Eintragen wichtig sein, ist es in Wirklichkeit aber vielleicht nicht mehr, und ungeahnte Probleme werden später möglicherweise wichtiger.
  Man kann schlecht ständig PRs hochladen, nur um TODO-Kommentare zu aktualisieren.
  Wenn man Aufgaben festhalten will, ist es besser, sie extern zu verwalten — in einem Issue-Tracker oder einer leicht aktualisierbaren Textdatei.
• Der Titel ist zwar etwas klickorientiert, aber dem Gesamtinhalt stimme ich voll zu.
  Ich habe eben erst mit #TODO eine extrem seltene Ausnahmesituation dokumentiert. Seit zwei Jahren ist sie nie eingetreten, aber falls ich mich später frage, warum ich diesen Teil nicht behandelt habe, hilft mir das weiter.
  Ich verstehe auch die Leute, die sagen, so etwas solle man einfach als Kommentar hinterlassen. Es hängt von der Art der Codebasis ab, und in einem Umfeld wie meinem mit einem Zwei-Personen-Team funktioniert der TODO-Ansatz gut.
  • Unser Team hat für so etwas // TBD: [...] verwendet. Das war ein Trick, damit Leute mit TODO-Zwang es nicht bemerken.
• Es braucht einen Ort, an dem bekannte Probleme festgehalten werden können, die zwar einen Wert haben, aber nicht getrackt werden müssen.
  Dinge also, die man realistisch nicht beheben will, bei denen man aber später vielleicht doch einmal per Ctrl-F nachsehen möchte, falls doch einmal Zeit zum Aufräumen bleibt.
  Ich finde es unsinnig, dass so viele Tools oder Prozesse TODOs als Code Smell betrachten.
  • Ich bin so einem Problem tatsächlich noch nicht begegnet.
    Für mich ist das am Ende nur eine Frage der Priorität, letztlich ein Broken-Window-Problem (die bekannte Metapher aus The Pragmatic Programmer).
    Wenn man wirklich beschlossen hat, etwas nicht zu beheben, dann sollte es besser in der Softwaredokumentation festgehalten werden.
• Das Beispiel aus dem Artikel

  // TODO: If the user triple-clicks this button, the click handler errors because [xyz]
  ist meiner Meinung nach weniger ein echtes TODO als einfach ein Kommentar.
  Solche erklärenden Kommentare sind klar hilfreich, aber als TODO sind sie schwer einzuordnen.
  Ein TODO sollte deutlich machen, dass tatsächlich etwas getan werden muss, etwa: „Diese Funktion sollte gemäß XYZ einen anderen Wert zurückgeben.“
  In diesem Sinn gehört ein TODO nicht vergraben in den Code, sondern in einen Issue-Tracker.
  Meiner Erfahrung nach sind TODOs oft nur eine Rechtfertigung dafür, wegen des Zeitdrucks bei PR-Freigaben Abstriche bei der Codequalität zu machen. Tatsächlich werden sie fast nie umgesetzt; übrig bleibt nur der Gedanke: „Irgendein späterer Entwickler mit mehr Zeit wird das schon irgendwann lösen.“

  • Kommentare sollen erklären, warum dieser Code so funktioniert, wie er funktioniert.
    Zum Beispiel ist schon ein einfaches
    // If the user triple-clicks this button, the click handler errors because [xyz]
    für sich genommen nicht eindeutig: Ist das ein Bug oder beabsichtigt?
    Ein TODO ist ein kurzes Signal im Sinn von „Hier gibt es etwas Unvollkommenes, beachte das, wenn du daran arbeitest.“
    Wenn es zwingend behoben werden muss, sollte es an anderer Stelle getrackt werden.
    Aber wenn man TODOs selbst reduzieren will, führt das aus meiner Sicht nur dazu, dass mehr Code undokumentiert bleibt.
  • Das Beispiel halte ich nicht für einen besonders guten TODO-Kommentar.
    In der Zeit könnte man den Bug auch gleich beheben oder stattdessen einen Kommentar wie „Triple-Click wird wegen [xyz] ignoriert“ hinterlassen.
    Wenn Auslöser und Ursache schon bekannt sind, ist die Arbeit meiner Meinung nach bereits zu 80 % erledigt.
  • Man kann es als eine Art „überspringen“ betrachten. Oft ist es völlig in Ordnung, etwas gar nicht anzugehen.
    Problematisch wird es, wenn man annimmt, der Code funktioniere vollständig, obwohl das nicht der Fall ist.
    Das beste TODO, das ich je gesehen habe, war etwas wie „TODO: encrypt this“ in sicherheitsrelevantem Code.
    Dadurch war für jeden sofort ersichtlich, dass dieser Code nicht verschlüsselt war, und es verringerte auch die Sorge, die Verschlüsselung werde vielleicht schon modular an anderer Stelle erledigt oder man würde versehentlich doppelt verschlüsseln.
  • Das gegebene Beispiel ist weniger ein TODO als eher ein FIXME.
    Es ist klar ein Fehler, aber einer mit eher geringer Notwendigkeit zur Bearbeitung.
• Ich widerspreche entschieden.
  Wenn man es nicht als Bug erfasst oder tatsächlich daran arbeiten will, sollte man kein TODO hinterlassen.
  // TODO: If the user triple-clicks this button, the click handler errors because [xyz]
  Das ist nur eine Beobachtungsnotiz. Das Wort TODO sollte dort weg.
• Ich verwende es ebenfalls hierarchisch.
  FIXME nutze ich, wenn etwas unbedingt behoben werden muss oder der nächste Schritt klar auf der Hand liegt.
  TODO nutze ich für gröbere Gedanken oder einfach, um etwas aus dem Kopf zu bekommen und mich auf die nächste Aufgabe konzentrieren zu können.
  Das kann vieles sein: wenn die Idee noch nicht ganz ausgereift ist, wenn ich mir noch nicht sicher bin, ob es wirklich nötig ist, oder wenn ich auf etwas Verwandtes warte.
  Wenn ich es nicht notiere, geistert es mir weiter im Kopf herum; sobald ich es aber als TODO oder sonst wie aufgeschrieben habe, ist das psychologisch eine enorme Erleichterung.
• Ich sehe Kommentare als ein Eingeständnis mangelnder Fähigkeit, Code zu schreiben.
  Am liebsten würde ich Code so schreiben, dass er auch ohne Kommentare sofort verständlich ist.
  Trotzdem schreibe ich am Ende doch Kommentare, wenn etwas selbst für mein späteres Ich noch zu verwirrend wäre.
  Das Traurige ist: Wenn später jemand den Code ändert und die Kommentare nicht aktualisiert, sorgt das nur für noch mehr Verwirrung.
  TODOs sollten meiner Meinung nach nicht in committedem Code stehen, sondern im Projekt- oder Issue-Management-System verwaltet werden.