Wer im Team arbeitet stößt unweigerlich auf auskommentierten Sourcecode. Dieser entsteht aus unterschiedlichsten Gründen. Manchmal wird etwas getestet. Ein anderes Mal bleibt er als Erinnerungsstütze während der Neuimplementierung. Hin und wieder vergisst man den auskommentierten Code schlichtweg zu löschen und manche haben einfach nur Angst davor.

Nichts von all dem rechtfertigt allerdings auskommentierten Code im Source Control. Meinen “Unmut” darüber hatte ich via Twitter kundgetan:

Neben zahlreichen Zustimmungen gab es natürlich auch einige Stimmen, die das überhaupt nicht so sehen und auskommentierten Sourcecode im Source Control als legitimes Mittel während einer Feature- oder Test-Implementierung hinstellen. Genau dazu möchte ich einige Worte loswerden.

Kontext

Zuerst möchte ich allerdings ein wenig Kontext herstellen. Einzelne Entwickler handhaben es gerne so, dass sie ihren täglichen (oder von mir aus auch stündlichen) Stand ins Source Control (eventuell auch als Feature-Branch) committen. Da geht es dann oft um das Thema Backup oder aber einfach nur um den Zugriff von unterschiedlichen Geräten aus. Viele der von mir genannten Punkte mögen für diesen Fall nicht zwingend relevant sein, da ich mich insbesondere auf Entwicklungsteams beziehe. Ebenfalls spreche ich nicht von Repositories in denen POCs oder Tests abgelegt werden, sondern eine RL-Anwendung.

Kommentare in Featurebranches

Natürlich kann man die Arbeit an einem Feature oder das Austesten von unterschiedlichen Varianten als Anlass nehmen, je nach Belieben Sourcecode auszukommentieren und im Source Control zu hinterlegen. Möglicherweise könnte man das sogar damit argumentieren, dass man ja der einzige aus dem Team ist, der damit arbeitet.

Tatsächlich ist das ganz schlechter Stil. Ein Feature (das einen eigenen Feature-Branch verlangt) ist hoffentlich in viele kleine Tasks zerlegt, die einzeln und unabhängig voneinander abgehandelt werden können. Ist ein Punkt umgesetzt bzw. funktionstüchtig, wird aufgeräumt und dann die Änderung an den Server übergeben.

Dabei wird das Aufräumen nicht prokrastiniert, sondern sofort erledigt. Alles was aufgeschoben wird, wird in der Regel nicht erledigt. Man lässt ja auch runter, bevor man das WC verlässt.

Werden unterschiedliche Möglichkeiten getestet, empfiehlt sich, dies in Form eines eigenständigen Tests zu machen. Losgelöst vom eigentlichen Produkt – gerne auch mit eigenen Builds. Das beste Ergebnis wird übernommen – und zwar sauber.

Source Control als Archiv

Wurden auszutauschende Codestellen identifiziert, behelfen sich manche Softwareentwickler, indem dieser auskommentiert und darunter der neue Code geschrieben wird. Der alte bleibt quasi als Gedankenstütze vorhanden. Dagegen ist nichts einzuwenden. Das ist für die eigentliche Implementierung sehr hilfreich, eine Übernahme des auskommentierten Codes ist allerdings wenig zielführend, denn er ist in der Historie ersichtlich und kann auch jederzeit wiederhergestellt werden.

Frühere Implementierungen können im Source Control ausfindig gemacht werden.

Tritt an dieser Stelle ein Problem auf, wird man einen Blick auf die Historie werfen und kann so dieses ausmachen bzw. gegebenenfalls wieder den alten Code aktivieren. Funktioniert alles wie es soll, bedarf es auch des alten Codes nicht mehr.

Appell ans Qualitätsbewusstsein

Natürlich kann es schon mal vorkommen, dass man die eine oder andere Zeile auskommentierten Code vergisst wegzuräumen. Vielleicht ist es manchmal auch wirklich gerade doof und man hat keine Lust nochmals über den Code zu gehen und zu prüfen, ob man die Stellen auch tatsächlich sauber verlässt. Im Endeffekt ist es aber ein Zeichen der Professionalität, dass man genau das tut.

Aufgeräumter Code steht für Professionalität.

Was denken wir denn von anderen Handwerkern, die ihre Behelfe nicht wegräumen oder die Baustelle schlimmer hinterlassen als sie sie aufgefunden haben?

Bewahre die Übersichtlichkeit

Schon mal ein Buch im Laden gekauft, aufgeschlagen und auskommentierte Absätze und dergleichen gefunden? Nein? Genau, das könnte der geneigte Leser niemals flüssig lesen. Innerhalb kürzester Zeit wird das Buch zur Seite gelegt oder zurückgebracht.

Wir Softwareentwickler verbringen die meiste Zeit mit Lesen von Sourcecode. Je leichter uns das gemacht wird und umso weniger uns von den wirklich wichtigen Stellen Code ablenken, desto konzentrierter und produktiver können wir arbeiten. Zudem sinken die Fehlerrate und der Mehraufwand.

Multiplikator Team

Ein Team verstärkt Verhaltensweisen. Das macht auch vor dem Auskommentieren von Sourcecode nicht halt. Wenn dies der Großteil des Teams praktiziert, dann sieht der Source innerhalb kürzester Zeit wie eine Müllhalde aus. Arbeiten macht damit keinen Spaß mehr und statt aufzuräumen werden manche kreativ und verwenden z.B. Regions um das einigermaßen lesbar zu bekommen. Das kann nun wirklich nicht das Ziel sein.

In der Regel gibt es den einen oder anderen im Team, der als unbemerktes Heinzelmännchen jeden auskommentierten Sourcecode wegwirft, damit das nicht vollkommen ausartet.

Es mag durchaus sein, dass die Arbeitsweise einzelner Entwickler auskommentierten Sourcecode im Source Control erlaubt oder sogar erfordert. Im Grunde ist man gewillt ihm das selbst zu überlassen, wenn er doch alleine arbeitet. Irgendwann arbeitet aber auch dieser Entwickler mit anderen zusammen, legt diese Arbeitsweise (aus Gewohnheit) aber nicht ab. Da kann man sich ausrechnen wohin das führt.

Keine Kommentare mehr im Sourcecode?

Dieser Beitrag ist kein Appell an die Kommentarlosigkeit innerhalb des Sourcecodes. Kommentare sind ein hilfreiches Mittel um an den relevanten Stellen ein Warum zu erklären oder auf eine Besonderheit hinzuweisen. Die Grundvoraussetzung ist natürlich die Pflege derselben.

Wird die Kommentarfunktion allerdings zum Deaktivieren oder Archivieren von Sourcecode verwendet, dann wird diese Funktionalität schlicht missbraucht. Das geht anders.

Wie ist deine Meinung zu diesem Thema?

Veröffentlicht von Norbert Eder

Ich bin ein leidenschaftlicher Softwareentwickler. Mein Wissen und meine Gedanken teile ich nicht nur hier im Blog, sondern auch in Fachartikeln und Büchern.

Beteilige dich an der Unterhaltung

1 Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

  1. Hallo Norbert,
    Du sprichst ein wichtiges Thema an. Es ist kaum zu glauben wie schnell Code unlesbar wird, wenn dort ständig nur auskommentiert wird. Einige Beispiele dazu habe ich selber vor kurzem auf https://improveandrepeat.com/2016/11/let-death-code-die/ beschrieben.

    Aus meiner Sicht gibt es nur eines: Code rigoros löschen, wenn dieser nicht mehr gebraucht wird. Für historische Nachforschungen hat man ja die Quellcode-Verwaltung und (hoffentlich) nützliche Commit-Meldungen.

Cookie-Einstellungen
Auf dieser Website werden Cookie verwendet. Diese werden für den Betrieb der Website benötigt oder helfen uns dabei, die Website zu verbessern.
Alle Cookies zulassen
Auswahl speichern
Individuelle Einstellungen
Individuelle Einstellungen
Dies ist eine Übersicht aller Cookies, die auf der Website verwendet werden. Sie haben die Möglichkeit, individuelle Cookie-Einstellungen vorzunehmen. Geben Sie einzelnen Cookies oder ganzen Gruppen Ihre Einwilligung. Essentielle Cookies lassen sich nicht deaktivieren.
Speichern
Abbrechen
Essenziell (1)
Essenzielle Cookies werden für die grundlegende Funktionalität der Website benötigt.
Cookies anzeigen