it-swarm.com.de

Wie kann ich mit einem Teammitglied umgehen, das es nicht mag, Kommentare im Code abzugeben?

Eines meiner Teammitglieder vermeidet konsequent Kommentare in seinem Code.

Sein Code ist nicht selbstdokumentierend, und andere Programmierer haben Schwierigkeiten, seinen Code zu verstehen.

Ich habe ihn mehrmals gebeten, seinen Code zu kommentieren, aber er gibt nur Ausreden oder behauptet, dass er es später tun wird. Sein Anliegen ist, dass das Hinzufügen von Kommentaren zu viel Zeit in Anspruch nimmt und die Projekte verzögert.

Welches Argument kann ich ihm vorlegen, um ihn davon zu überzeugen, seinen Code ordnungsgemäß zu dokumentieren?

Bin ich in diesem Sinne falsch, mich auf die Codekommentare zu konzentrieren, oder deutet dies auf ein größeres Problem hin, das angegangen werden sollte?

186

Kommentare allein sorgen nicht für besseren Code, und wenn Sie nur auf "mehr Kommentare" drängen, erhalten Sie wahrscheinlich kaum mehr als /* increment i by 1 */ Stil Kommentare.

Fragen Sie sich also warum Sie möchten diese Kommentare. "Es ist Best Practice" zählt nicht als Argument, es sei denn, Sie verstehen warum.

Der auffälligste Grund für die Verwendung von Kommentaren ist, dass der Code leichter zu verstehen ist. Wenn sich Leute über fehlende Kommentare beschweren, sind sie entweder ahnungslose Papageien oder es fällt ihnen schwer, den Code zu verstehen, mit dem sie arbeiten.

Beschweren Sie sich also nicht über fehlende Kommentare: Beschweren Sie sich über unlesbaren Code. Oder noch besser, beschweren Sie sich nicht, stellen Sie einfach weiter Fragen zum Code. Fragen Sie bei allem, was Sie nicht verstehen, die Person, die es geschrieben hat. Du solltest das sowieso tun; Mit unlesbarem Code stellen Sie einfach weitere Fragen. Wenn Sie später zu einem Code zurückkehren und sich nicht sicher sind, ob Sie sich richtig daran erinnern, was er tut, stellen Sie dieselbe Frage erneut.

Wenn Kommentare das Problem beheben können und Ihr Kollege ein funktionierendes Gehirn hat, wird er/sie irgendwann feststellen, dass das Kommentieren des Codes viel einfacher ist, als wenn Sie ständig dumme Fragen stellen. Und wenn Sie keine Fragen haben, ist dieser Code möglicherweise bereits perfekt lesbar, und Sie sind schuld - schließlich benötigt nicht jeder Code Kommentare.

Vermeiden Sie es, in Bezug auf die Fähigkeiten der Menschen um jeden Preis herablassend oder beschuldigend zu klingen. Sei ernst und ehrlich mit deinen Fragen.

432
tdammers

Ich habe viele Entwickler getroffen, die Probleme hatten, selbstdokumentierenden Code oder hilfreiche Kommentare zu schreiben. Diesen Menschen fehlt oft genug Selbstdisziplin oder Erfahrung, um es richtig zu machen.

Was niemals funktioniert, ist "ihnen zu sagen, dass sie weitere Kommentare hinzufügen sollen". Dies erhöht weder ihre Selbstdisziplin noch ihre Erfahrung. IMHO könnte das einzige, was funktionieren könnte, häufige Codeüberprüfungen und Refactoring-Sitzungen durchführen. Wenn ein Entwickler eine Aufgabe erledigt hat, erlauben Sie ihm, alle Teile des Codes zu erklären, die Sie nicht verstehen. Refaktorieren oder dokumentieren Sie den Code sofort so, dass Sie beide 6 Monate später verstehen.

Tun Sie dies über einen Zeitraum von einigen Monaten, mindestens zweimal pro Woche. Wenn Sie Glück haben, lernen die anderen Entwickler diese Sitzungen, damit Sie die Überprüfungshäufigkeit reduzieren können.

114
Doc Brown

Ich bin überrascht, dass noch niemand Code-Reviews erwähnt hat. Machen Sie Code-Reviews! Wenn er einen Check-in von schlechter Qualität hat, sagen Sie nicht einfach "Kommentare hinzufügen". Stellen Sie ständig Fragen und lassen Sie sich von ihm sagen, was sein Code bewirkt und warum. Mache Notizen. Geben Sie ihm am Ende der Codeüberprüfung eine Kopie der Notizen und bitten Sie ihn, Ihre Fragen ziemlich offensichtlich zu machen. Entweder durch mehr Kommentare oder durch einfaches Umgestalten seines Codes, um die Qualität zu verbessern (vorzugsweise letzteres, wenn möglich).

27
Earlz

Dies hängt vom Code ab, den Ihr Teamarbeiter erstellt. Wenn Sie das Buch Clean Code von Onkel Bob lesen, werden Sie feststellen, dass er es tatsächlich vorzieht, keine Kommentare zum Code hinzuzufügen. Wenn der Code selbst so lesbar ist, wie er sein sollte, sind kaum Kommentare erforderlich.

Wenn dies nicht der Fall ist oder Sie aufgrund einer nicht verhandelbaren Richtlinie Kommentare benötigen, stellt sich die Hauptfrage, ob nur Sie ihn wollen/sie, um Kommentare zu schreiben, oder ob es sich um das gesamte Team oder den Team-/Projektleiter handelt. Wenn es nur Sie sind, sollten Sie mit Ihren anderen Kollegen sprechen, um herauszufinden, warum dies möglicherweise überhaupt keine so große Sache ist.

Wenn dem Projektleiter die Kommentare fehlen, können Sie sie auch als Teil der Vollständigkeit anfordern, d. H. Wenn der übermittelte Code keinen Kommentar enthält, ist die Arbeit noch nicht abgeschlossen. Er darf andere Arbeiten erst fortsetzen, wenn seine aktuelle Arbeit beendet ist und dafür Kommentare erforderlich sind. Beachten Sie jedoch, dass diese Art des Erzwingens höchstwahrscheinlich zu schrecklichen Kommentaren führen wird (erwarten Sie eine Menge beschissener Wiederholungen von Codekommentaren).

Meiner bescheidenen Meinung nach ist es nur möglich, die tatsächlichen Gewinne zu besprechen, die Sie und alle anderen aus Kommentaren ziehen. Wenn er/sie es nicht durch bloße Diskussion versteht, gibt es auch immer den schwierigen Weg: Anstatt sie neuen Code schreiben zu lassen, lassen Sie sie an vorhandenem Code arbeiten. Wenn möglich, sollten Sie zwei verschiedene Arbeitsbereiche finden - einen mit nützlichen Kommentaren und einen ohne Kommentare. Das Lesen des nicht lesbaren, nicht kommentierten Codes einer anderen Person ist ein Augenöffner für Ihre eigene Arbeit.

Wir waren alle einmal dort und waren wütend auf den ursprünglichen Autor einer Quelle, weil er so schlampig gearbeitet hat. Es ist die zusätzliche Überlegung, dass jeder von uns auch ein solcher Autor ist, die Ihnen klar macht, dass Sie sich um die Lesbarkeit kümmern sollten. Vergessen Sie daher nicht, die Ergebnisse anschließend mit Ihrem Kollegen zu besprechen, um diese Überlegung zu fördern.

18
Frank

Wenn Sie einen Mitarbeiter haben, der den Anweisungen nicht folgen kann, tadeln Sie ihn und stellen Sie sicher, dass klar ist, dass dies seinem beruflichen Aufstieg nicht hilft. Die Konsistenz des Codierungsstils ist für ein Team von entscheidender Bedeutung. Wenn alle anderen Kommentare schreiben und dies nicht der Fall ist, wird dies den Codierungsstil beeinträchtigen.

Das heißt, Sie können ihm wahrscheinlich helfen. Nach meiner Erfahrung gibt es eine psychologische Barriere, wenn jemand gegen dieses Kommentieren protestiert dauert zu lange wie…

  1. Er ist sich seiner Code-/Design-Entscheidungen bewusst und möchte sie nicht in Prosa auslegen. (Codeüberprüfungen können hilfreich sein, um das Selbstvertrauen einer Person zu stärken und sie zu zerstören.)
  2. Er arbeitet sehr linear und denkt nicht viel voraus. Das Kommentieren ist schmerzhaft, weil es ihn zwingt, den Code, den er gerade schreiben wollte, aus seinem Arbeitsgedächtnis zu entladen, um seine Absicht auf eine andere Art und Weise zu verfassen. (Wenn dies zutrifft, wird das Kommentieren für seine Codequalität sehr wichtig.)
  3. Historisch gesehen verstehen die Leute seine Kommentare nicht.

Für einen Programmierer ist es wichtig zu erkennen, dass Kommentare wie Tests sind: Sie sind nicht nur für die zukünftige Verwendung - sie sind für den Programmierer selbst. Sie zwingen ihn, anders über seinen Ansatz nachzudenken.

Nichts davon ist ein Ersatz für CI, Tests oder Codeüberprüfungen. Es ist nur einer von vielen kritischen Teilen der Codierung, die selbst keinen Code schreiben.

10
kojiro

Holen Sie sich Code-Überprüfungssoftware und verwenden Sie sie gut.

Wir benutzen Kiln und wir lieben es. Wir haben die Richtlinie, dass jeder Änderungssatz überprüft werden muss (obwohl wir Entwicklern erlauben, Überprüfungen für Tags und konfliktfreie Zusammenführungen für sich selbst zu erheben/zu genehmigen (obwohl die meisten von uns rebaseif verwenden); auf diese Weise können wir Änderungssätze ohne Überprüfungen schnell erkennen).

Unklarer Code ist der Grund dafür, dass eine Codeüberprüfung abgelehnt wird. Es spielt keine Rolle, ob es sich bei dem Fix um Kommentare oder um klareren Code handelt, aber der Prüfer muss ihn verstehen können. Einige Entwickler bevorzugen es, den Code neu zu schreiben, aber andere (ich selbst eingeschlossen) finden es oft einfacher, Absichten in Kommentaren auszudrücken (Code kann leicht zeigen, was er tut, aber es ist schwieriger zu zeigen, was er tut sollte tun).

Wenn es jemals Fragen zur Klarheit des Codes gibt, gewinnt der Prüfer immer. Natürlich versteht der Autor es, weil sie es geschrieben haben. Es muss einer anderen Person klar sein.

Durch die Verwendung von Software wie Kiln wird kein Änderungssatz übersehen. Jeder in meinem Entwicklerteam bevorzugt es so. Codeüberprüfungssoftware hat einen großen Einfluss sowohl auf unsere Codequalität als auch auf die Anwendungsqualität :-)

Es ist für Entwickler leicht, bei der ersten Einführung von Software mit abgelehnten Bewertungen defensiv zu werden, aber meiner Erfahrung nach dauert es nicht lange, bis sie erkennen, dass die Dinge auf diese Weise besser sind, und sie annehmen :-)

Bearbeiten: Es ist auch erwähnenswert, dass Entwickler nicht versuchen, kryptischen Code mündlich oder in Kommentaren in der Rezension zu erklären. Wenn etwas nicht klar ist, können Sie es am besten im Code erklären (in Kommentaren oder durch Refactoring). Fügen Sie dann die neuen Änderungssätze derselben Überprüfung hinzu.

8
Danny Tuppeny

Interessant ist, dass Lesbarkeit in Bezug auf die natürliche Sprache an der Geschwindigkeit des Lesens und Verstehens gemessen wird. Ich denke, eine einfache Regel kann tatsächlich übernommen werden, Wenn ein bestimmter Codekommentar diese Eigenschaft nicht verbessert, kann dies vermieden werden.

Warum Kommentare?

Obwohl Codekommentar eine Form der eingebetteten Dokumentation ist, gibt es in High-End-Programmiersprachen mehrere Möglichkeiten, um überflüssige "überdokumentierte" Programmierung (von aussagekräftigem Code) durch Verwendung von Elementen der Sprache selbst zu vermeiden. Es ist auch eine schlechte Idee, Code in Listen aus Programmierlehrbüchern umzuwandeln, in denen einzelne Aussagen buchstäblich auf fast tautologische Weise erklärt werden (beachten Sie das Beispiel "/ * inkrementiere i um 1 * /" in bereits bereitgestellten Antworten), um solche Kommentare relevant zu machen nur für Programmierer, die mit der Sprache unerfahren sind.

Dennoch ist es die Absicht, den "unterdokumentierten" (aber bedeutungslosen) Code zu kommentieren, der wirklich "die Quelle allen Übels" ist. Die bloße Existenz von "unterdokumentiertem" Code ist ein schlechtes Signal - entweder ist es ein unstrukturiertes Durcheinander oder ein verrückter Hack von mystisch verlorenem Zweck. Offensichtlich ist der Wert eines solchen Codes zumindest fraglich. Leider gibt es immer Beispiele, bei denen es in der Tat besser ist, einen Kommentar in einen Abschnitt (visuell gruppierter) formatierter Codezeilen einzufügen, als ihn in eine neue Unterroutine zu packen (beachten Sie die "dumme Konsistenz", die "der Hobgoblin der kleinen Köpfe" ist). .

Lesbarkeit des Codes! = Codekommentare

Für lesbaren Code sind keine Anmerkungen durch Kommentare erforderlich. An jeder bestimmten Stelle im Code gibt es immer einen Kontext einer Aufgabe, die dieser bestimmte Code erfüllen soll. Wenn der Zweck fehlt und/oder der Code etwas Geheimnisvolles tut = vermeiden Sie ihn um jeden Preis. Lassen Sie nicht zu, dass seltsame Hacks Ihren Code füllen - dies ist ein direktes Ergebnis der Kombination von Buggy-Technologien mit Zeit-/Interessemangel, um die Grundlagen zu verstehen. Vermeiden Sie mystischen Code in Ihrem Projekt!

Andererseits kann Lesbares Programm = Code + Dokumentation Mehrere legitime Abschnitte von Kommentaren enthalten, z. um die Erstellung von "Kommentaren zur API" -Dokumentation zu erleichtern.

Befolgen Sie die Standards für den Codestil

Komischerweise geht es bei der Frage nicht darum, warum man Code kommentiert, sondern um Teamarbeit - wie man Code in hochsynchronisiertem Stil (den jeder andere lesen/verstehen kann) erzeugt. Befolgen Sie in Ihrem Unternehmen Standards für den Codestil? Der Hauptzweck besteht darin, zu vermeiden, dass Code geschrieben wird, der umgestaltet werden muss, zu "persönlich" und "subjektiv" mehrdeutig ist. Wenn man also die Notwendigkeit sieht, den Codestil zu verwenden, gibt es eine ganze Reihe von Tools, wie man ihn richtig implementiert - angefangen bei der Schulung der Mitarbeiter bis hin zur Automatisierung für die Qualitätskontrolle des Codes (zahlreiche Zeilen usw.) und (Überarbeitung) Steuerung integriert) Code-Überprüfungssysteme.

Werden Sie Evangelist für Lesbarkeit von Codes

Wenn Sie damit einverstanden sind, dass Code häufiger gelesen als geschrieben wird. Wenn Ihnen ein klarer Ausdruck von Ideen und klarem Denken wichtig ist, egal welche Sprache für die Kommunikation verwendet wird (Mathematik, Maschinencode oder altes Englisch). Wenn Ihre Mission darin besteht, langweilige und hässliche Wege des alternativen Denkens auszurotten. (Entschuldigung , der letzte stammt aus einem anderen "Manifest") .. Fragen stellen, Diskussionen einleiten, zum Nachdenken anregende Bücher über Code-Reinigung verbreiten (wahrscheinlich nicht nur etwas Ähnliches wie Becks Designmuster, sondern eher wie bereits erwähnt von RC Martin) ) welche Mehrdeutigkeit in der Programmierung ansprechen. Weiter geht es mit einer Stichpunktpassage der wichtigsten Ideen (zitiert aus dem O'Reilly-Buch über Lesbarkeit).

  • Vereinfachen Sie das Benennen, Kommentieren und Formatieren mit Tipps, die für jede Codezeile gelten
  • Verfeinern Sie die Schleifen, die Logik und die Variablen Ihres Programms, um Komplexität und Verwirrung zu reduzieren
  • Angriffsprobleme auf Funktionsebene, z. B. die Neuorganisation von Codeblöcken, um jeweils eine Aufgabe auszuführen
  • Schreiben Sie effektiven Testcode, der gründlich und präzise sowie lesbar ist

Wenn man das "Kommentieren" ausschneidet, bleibt immer noch viel übrig (ich denke , Code zu schreiben, der keine Kommentare benötigt , ist eine großartige Übung!). Die Benennung semantisch aussagekräftiger Bezeichner ist ein guter Anfang. Als nächstes strukturieren Sie Ihren Code, indem Sie logisch verbundene Operationen in Funktionen und Klassen gruppieren. Und so weiter. Ein besserer Programmierer ist ein besserer Schriftsteller (natürlich unter der Annahme anderer technischer Fähigkeiten).

4

liege ich falsch, wenn ich mich auf die Codekommentare konzentriere, oder deutet dies auf ein größeres Problem hin, das behoben werden sollte?

Etwas. Großartiger Code benötigt keine Kommentare. Wie Sie sagten, ist sein Code jedoch nicht selbstdokumentierend. Ich würde mich also nicht auf die Kommentare konzentrieren. Sie sollten sich darauf konzentrieren, die Fähigkeiten und die Handwerkskunst Ihrer Entwickler zu verbessern.

Wie geht das? Doc Browns Vorschläge zu Überprüfungen/Refactoring-Sitzungen sind eine gute Idee. Ich finde die Paarprogrammierung noch effektiver, aber es kann auch erheblich schwieriger sein, sie zu implementieren.

3
Pete

Zunächst würde ich vorschlagen, dass Sie Ihren Ansatz bezüglich der Kommentare erneut ansprechen.

Wenn es sich um Dokumentationskommentare auf API-Ebene handelt (die später öffentlich zugänglich gemacht werden), macht dieser Entwickler seine Arbeit einfach nicht. Aber für alle anderen Kommentare sei vorsichtig.

In den meisten Fällen, in denen ich ihnen begegne, sind Kommentare böse. Ich würde empfehlen, das Kapitel mit den Codekommentaren von "Clean Code" von Robert Martin zu lesen, um ein gutes Verständnis dafür zu erhalten, warum.

Kommentare schaden Ihrem Code auf verschiedene Weise:

1) Sie sind schwer zu pflegen. Beim Refactoring müssen Sie zusätzliche Arbeit leisten. Wenn Sie die im Kommentar beschriebene Logik ändern, müssen Sie auch den Kommentar bearbeiten.

2) Sie lügen oft. Sie können Kommentaren nicht vertrauen und müssen stattdessen den Code lesen. Was die Frage aufwirft: Warum brauchen Sie die Kommentare überhaupt?

// this method returns the sum of 'a' and 'b'
public int GetHash(int a, int b)
{
    //the calculation of the hash
    int result = a*b;
}

(Der Hash ist nicht die Summe, sondern das Produkt.)

3) Kommentare überladen den Code und fügen sehr selten einen Wert hinzu.

Meine Lösung: Anstatt weitere Kommentare hinzuzufügen, versuchen Sie, sie überhaupt loszuwerden!

3
Paul

Angesichts der oft extremen Ansichten zum Kommentieren zögere ich, abzuwägen. Davon abgesehen ...

Welche Argumente kann ich vorbringen, wenn Sie (unlesbaren) Code schreiben, der ordnungsgemäß dokumentiert werden sollte?

Das Verstehen, wie wartbarer und lesbarer Code geschrieben wird, erfordert Zeit, Übung und Erfahrung. Unerfahrene Programmierer (und leider viele erfahrene) leiden häufig unter dem Ikea-Effekt ( PDF ). Das liegt daran, dass sie es erstellt haben und mit ihm bestens vertraut sind und sicher sind, dass der Code nicht nur großartig, sondern auch lesbar ist.

Wenn die Person ein großartiger Programmierer ist, ist wenig oder gar keine Dokumentation erforderlich. Die meisten Programmierer sind jedoch nicht großartig und ein Großteil ihres Codes wird in der Abteilung "Lesbarkeit" leiden. Die mittelmäßige oder sich entwickelnde Programmiererin zu bitten, "ihren Code zu erklären", ist insofern nützlich, als sie gezwungen ist, ihren Code kritischer zu betrachten.

Bedeutet dies, ihren Code zu "dokumentieren"? Nicht unbedingt. In diesem Fall hatte ich in der Vergangenheit einen ähnlichen Programmierer mit diesem Problem. Ich habe ihn gezwungen zu dokumentieren. Leider war seine Dokumentation so nicht zu entziffern wie sein Code und fügte nichts hinzu. Im Nachhinein wären Codeüberprüfungen hilfreicher gewesen.

Sie (oder ein Delegierter) sollten sich mit diesem Programmierer zusammensetzen und einen Teil seines älteren Codes abrufen. Nicht das neue Zeug, das er kennt, wenn er nur daran arbeitet. Sie sollten ihn bitten, Sie mit minimaler Interaktion durch seinen Code zu führen. Dies könnte auch eine separate "Dokumentations" -Sitzung sein, in der er seinen Code schriftlich erklären soll. Dann sollte er Feedback zu besseren Ansätzen bekommen.

Nebenbei bemerkt ... manchmal wird eine Dokumentation benötigt, unabhängig davon, wie gut die "Lesbarkeit" des Codes ist. APIs sollten über eine Dokumentation verfügen, äußerst technische und komplexe Vorgänge sollten über eine Dokumentation verfügen, die dem Programmierer hilft, die beteiligten Prozesse zu verstehen (häufig außerhalb des Wissensbereichs des Programmierers), und einige Dinge wie komplexe reguläre Ausdrücke sollten wirklich dokumentieren, womit Sie übereinstimmen.

1
Bill

Dies ist größtenteils eine Erweiterung der Antwort von tdammers, führt jedoch in regelmäßigen Abständen Codeüberprüfungen durch.

Wenn er (und andere Entwickler) sich hinsetzen, ihren Code durchgehen und mehr oder weniger vor ihren Vorgesetzten und Kollegen verteidigen, werden alle zu besseren Programmierern und schaffen in relativ kurzer Zeit einen echten Mehrwert. Kurzfristig gibt es dem betreffenden Entwickler keine Entschuldigung, seinen Code zum Zeitpunkt der Überprüfung ordnungsgemäß zu kommentieren.

BEARBEITEN: Ich bin mir nicht sicher, warum jemand meinen Vorschlag ablehnen würde - vielleicht habe ich angenommen, dass die Vorteile der Codeüberprüfung allgemein bekannt sind ... In diesem Thread finden Sie eine Community-Analyse der Praxis:

Überprüft Code bewährte Verfahren?

1
LJ2

Wenn ein Teammitglied Probleme hat, den Code eines anderen Teammitglieds zu verstehen (aus irgendeinem Grund); Dann sollte dieses Teammitglied in der Lage sein, herauszufinden, wer den Originalcode geschrieben hat (ein vernünftiges Revisionskontrollsystem), und sollte aufgefordert werden, den Autor des Codes zu bitten, ihn direkt zu erklären (z. B. zu seinem Schreibtisch gehen, sich hinsetzen und darüber diskutieren).

In diesem Fall verbringt die Person, die ihren Code nicht angemessen kommentiert, einen großen Teil ihrer Zeit damit, zu erklären, was sie getan hat, wenn das Fehlen von Kommentaren ein Problem darstellt. und (wenn sie klug sind) werden Kommentare hinzugefügt, um zu vermeiden, dass Sie Zeit mit all diesen Erklärungen verbringen.

Beachten Sie, dass es aus anderen Gründen wertvoll ist, Teammitglieder zu ermutigen, sich gegenseitig um Erklärungen zu bitten. Zum Beispiel ist ein Teammitglied möglicherweise weniger erfahren und kann Dinge von den erfahreneren Teammitgliedern lernen.

Indem Sie die Teammitglieder dazu ermutigen, sich gegenseitig um Erklärungen zu bitten, schaffen Sie meistens ein selbstausgleichendes System. wo verschiedene Teammitglieder sich automatisch "anpassen".

1
Brendan

Ich liebe die Antworten zur Codeüberprüfung, aber vielleicht hilft mein Prozess auch ein wenig.

Ich liebe Kommentare, aber ich füge sie fast nie beim ersten Durchgang in den Code ein. Vielleicht ist es nur mein Stil, aber ich werde den gleichen Abschnitt des Codes 3 bis 5 Mal während der Entwicklung treffen (Refactoring, Schreiben von Tests usw.).

Immer wenn ich etwas verwirrt bin oder wenn mir jemand eine Frage zu einem Codeabschnitt stellt, versuche ich, diese so zu beheben, dass sie sinnvoll ist.

Dies kann so einfach sein wie das Hinzufügen eines Kommentars, um eine verwirrende Reihe von Operationen in ihre eigene Funktion zu entfernen, oder es kann einen größeren Refaktor wie das Extrahieren eines neuen Objekts auslösen.

Ich schlage vor, dass Sie alle Mitglieder der Gruppe dazu ermutigen, zu "besitzen", dass ihr Code für andere lesbar ist. Dies bedeutet, dass Sie sich jedes Mal, wenn Ihnen jemand eine Frage zu Ihrem Code stellt, zu einer Änderung verpflichten - oder besser noch damit koppeln Person, um die Änderung sofort vorzunehmen!

Erwägen Sie ernsthaft, dies als Teil Ihres "Teamvertrags" voranzutreiben (und erstellen Sie definitiv einen Vertrag, wenn Sie keinen haben) - auf diese Weise haben sich alle darauf geeinigt und Sie haben ihn irgendwo an einer Wand, so dass es keinen gibt. Keine Frage zu dem, was Sie zugestimmt haben.

0
Bill K

Viele Projekte erfordern eine Codedokumentation: Schnittstellendokument, Entwurfsdokument, ...

Einige Projekte erfordern, dass solche Dokumentationen in Codekommentare eingefügt und mit Tools wie Doxygen oder Sphinx oder Javadoc extrahiert werden, damit Code und Dokumentation konsistenter bleiben.

Auf diese Weise müssen Entwickler nützliche Kommentare in Code schreiben, und diese Aufgabe ist in die Projektplanung integriert.

0
mouviciel

Wenn Sie einen guten Codierungsstandard befolgen, ist eine Mindestanzahl von Kommentaren erforderlich. Namenskonventionen sind wichtig. Methodennamen und Variablennamen sollten ihre Rolle beschreiben.

Meine TL schlägt mir vor, weniger Kommentare zu verwenden. Er möchte, dass mein Code verständlich und selbsterklärend ist. einfaches Beispiel: Variablenname für den Zeichenfolgentyp, der für das Suchmuster verwendet wird

   var str1:String="" //not uderstandable
   var strSearchPattern:String="" //uderstandable
0
M.S.Nayak

Ich werde sagen, worauf die meisten Antworten und Kommentare hinweisen: Sie müssen wahrscheinlich das eigentliche Problem hier herausfinden, anstatt zu versuchen, Ihre wahrgenommene Lösung durchzusetzen.

Sie sind motiviert, Kommentare in seinem Code zu sehen. warum? Du hast einen Grund angegeben; warum ist dir dieser Grund so wichtig? Er ist motivierter, stattdessen etwas anderes zu tun; warum? Er wird einen Grund angeben; warum ist ihm dieser Grund so wichtig? Wiederholen Sie diesen Vorgang, bis Sie die Ebene erreicht haben, auf der der Konflikt tatsächlich auftritt, und versuchen Sie dort eine Lösung zu finden, mit der Sie beide leben können. Ich wette, es hat sehr wenig mit Kommentaren zu tun.

0
reinierpost

Vielleicht muss dieser Typ eine Wertschätzung für gute Codierungsdisziplin erhalten und warum es für andere wichtig ist, den von ihm geschriebenen Code verstehen zu können.

Ich habe in meiner Karriere an einigen wirklich schrecklichen Codebasen gearbeitet, bei denen der Code so schlecht organisiert war, die Variablennamen so schlecht waren, die Kommentare so schlecht oder nicht vorhanden waren, dass die Codebasis meine Produktivität beeinträchtigte. Sie können nicht daran arbeiten, eine Codebasis zu reparieren oder zu verbessern, die Sie nicht verstehen. Wenn sie so geschrieben ist, dass sie für Neulinge undurchdringlich ist, verbringen sie mehr Zeit damit, sie zu verstehen, als tatsächlich daran zu arbeiten.

Es gibt keinen besseren Lehrer als harte Erfahrung!

In jeder Codebasis lauern einige schreckliche Teile, Teile des Systems, die niemand berühren möchte, weil sie Angst haben, etwas zu beschädigen, oder sie können keine sinnvolle Arbeit leisten, weil derjenige, der den Code geschrieben hat, längst abgewichen ist und ihr Verständnis genommen hat des Codes mit ihnen. Wenn dieser Code nicht kommentiert und nicht selbstdokumentierend ist, macht er die Sache nur noch schlimmer.

Ich schlage vor, Sie finden das Teil Ihrer Codebasis, das so ist, und geben Ihrem lästigen Codierer die Verantwortung dafür. Geben Sie ihm das Eigentum daran, machen Sie es zu seiner Verantwortung, lassen Sie ihn den wahren Schmerz der Arbeit an Code lernen, der nicht gewartet werden kann, weil er nicht gut dokumentiert oder in kurzer Zeit nicht zu verstehen ist. Nach ein paar Monaten Arbeit bin ich sicher, dass er anfangen wird, herumzukommen.

0
GordonM