Warum fehlen einigen OpenSouce-Bibliotheken Kommentare?

Ich weiß nicht, ob dies bei den meisten Opensource-Bibliotheken der Fall ist, aber viele von mir kennen und verwenden (z. B. OpenSSL, Webkit, ...), denen alle Kommentare fehlen oder die nur sehr wenige Kommentare enthalten.

Ganz zu schweigen von den wenigen Dokumenten, deren Quellcode schwer zu lesen ist. Wir können kaum verstehen, was eine Mitgliedsvariable bedeutet oder was diese Funktion bewirkt. Dies scheint gegen die Kodierung der Standardpraxis zu verstoßen

Warum ist das so? Wie können Menschen mit sehr wenigen Kommentaren an dieser Open Source zusammenarbeiten?

Das Schreiben von Quellcode macht Spaß.

Das Schreiben von Dokumentation und das Kommentieren von Code macht weniger Spaß.

Wenn ein Entwickler in einem Unternehmen arbeitet, das gute Kommentare und Dokumentationen erzwingt, gibt es keine Wahl: Entweder schreibt dieser Entwickler diese oder er ist dem Risiko ausgesetzt, entlassen zu werden.

Wenn ein Entwickler zu einem Open Source-Projekt beiträgt, macht er dies kostenlos und vor allem zum Spaß. Es gibt niemanden, der diesen Entwickler dazu zwingt, Dinge zu tun, zu denen er nicht bereit ist, wie das Schreiben von Dokumentation und Kommentaren.

Aus diesem Grund fehlen vielen Open Source-Projekten umfangreiche Dokumentationen und Kommentare.

Wie können Menschen ohne Dokumentation oder Kommentare noch zu Open Source-Projekten beitragen?

• Wenn der Quellcode von hoher Qualität ist, werden Kommentare nicht zu oft benötigt. Die Kommentare der öffentlichen Schnittstellen und die Dokumentation sind besonders nützlich für das Projekt Verbraucher, dh Entwickler , die einfach verwenden Bibliotheken, nicht zu ihnen beitragen.

• Es ist kein Produktivitätsfaktor beteiligt. Ich arbeite in einem Unternehmen, in dem die eigentliche Codebasis keine Komponententests, keine Dokumentation und keine Kommentare enthält. Ich verbringe viel Zeit damit, herauszufinden, was eine 600-LOC-Methode tut, oder Dinge zu codieren, die bereits erledigt sind, aber aufgrund fehlender Dokumentation nicht auffindbar sind. Daher verschwende ich die meiste Zeit einfach das Geld des Unternehmens, anstatt etwas zu tun wertvoll.

  Auf der anderen Seite spielt es für ein Open-Source-Projekt keine Rolle, ob einer der Mitwirkenden eine Woche verschwendet hat, weil keine Dokumentation oder keine richtigen Kommentare vorhanden sind. Das Schlimmste, was passieren kann, ist, dass dieser Mitwirkende das Projekt verlässt.

  Das Erkennen von Code ohne Kommentare oder Dokumentation kann sogar eine Herausforderung sein, dh einige Mitwirkende anziehen, anstatt sie zu entmutigen.

• In Unternehmensprojekten ist es nicht ungewöhnlich, dass ein Entwickler gezwungen ist, an allen Aspekten eines Produkts zu arbeiten, und einige Jahre später fast das gesamte System kennen muss. Bei einem Open-Source-Projekt zwingt Sie niemand, das Ganze zu kennen. Sie können einfach zu einem winzigen Teil davon beitragen und verfügen über ausgezeichnete Kenntnisse dieses Teils, ohne dass eine Dokumentation erforderlich ist.

Mehrere Gründe.

• Das Schreiben von Dokumentation ist nicht Spaß, und für viele Projekte, die Nutzerbasis ist das Programmierteam; Jeder weiß, worum es im Code geht, daher wird die Dokumentation nicht wirklich als wichtiger Aspekt des Projekts angesehen.
• Die Dokumentation kann (und wird) veraltet sein, und veraltete Dokumentation ist schlechter als gar keine. Dies bedeutet, dass die Dokumentation eine zusätzliche Belastung darstellt und die Flexibilität Ihrer Codebasis beeinträchtigen kann (mehr Dokumentation bedeutet für jede Änderung, dass Sie den Code und die Dokumentation aktualisieren müssen ). Insbesondere für sehr spezifische Open-Source-Projekte ist dies ein gültiges Argument, um eine minimale Dokumentation anzustreben und stattdessen lesbaren Code zu schreiben.
• Die Wirtschaftlichkeit von Open Source-Software ist unterschiedlich. Während es gut ist, Mitwirkende an Ihrem Projekt zu haben, handelt es sich bei vielen Projekten um Projekte vom Typ Scratch-and-Itch, die der Autor geschrieben hat, um ein bestimmtes Problem zu lösen, und die dann einfach so wie sie sind im Freien veröffentlicht wurden. Da Sie im Grunde genommen die Semmelbrösel eines anderen essen, ist die Einstellung, dass Sie nicht in der Lage sind, etwas zu verlangen, geschweige denn Dokumentation.

Wie können Menschen mit sehr wenigen Kommentaren an dieser Open Source zusammenarbeiten?

Angenommen, Sie meinten "Wie können Leute mit diesem schwer lesbaren Open-Source-Code zusammenarbeiten?" - nun, ich denke, ein Open-Source-Projekt mit schlechtem Code wird einfach weniger Mitwirkende haben, als es mit gutem Code hätte tun können. Vergessen Sie jedoch nicht, dass die Lesbarkeit von Code immer im Auge des Betrachters liegt und der meiste Open-Source-Code nicht so schlecht ist, dass Sie zumindest ein bisschen oder die Absichten einiger Funktionen und Klassen nicht verstehen können.

Wenn Sie etwas zu einem Open Source-Projekt beitragen möchten, müssen Sie häufig nicht das Ganze verstehen, sondern nur die Teile, in denen Sie eine bestimmte Funktion hinzufügen möchten. Wenn ein Entwickler ein fehlendes Feature benötigt, wird er höchstwahrscheinlich in die Kugel beißen, die Teile identifizieren, die er ändern muss, diese Teile mental "dekodieren" und die neuen Features dort hinzufügen. Wenn er gut ist, wird er auch versuchen, die "dekodierten" Teile zu überprüfen und umzugestalten, aber ich denke, in der Praxis wird dies zu selten vorkommen.