Teammitglied ist vehement gegen Codeformatierung

Ich bin der Manager eines kleinen Teams von Entwicklern (5 Ingenieure, mich eingeschlossen).

Vor einigen Monaten haben wir auf Anregung eines anderen Kollegen für unser Hauptprojekt eine obligatorische Codeformatierung in die Codebasis eingeführt. Unser Projekt ist in Python und das Formatierungstool ist black(nicht relevant, denke ich).

Ich finde es wertvoll, dass der Code in allen Projektdateien das gleiche „Aussehen“ hat, für mich ist es Teil der Qualitätssicherung für das gesamte Projekt. Code-Merge-Anfragen müssen mit dem Tool formatiert werden, sonst können sie nicht zur Software hinzugefügt werden.

Seitdem beschwert sich immer wieder ein Kollege und widerspricht dieser Entscheidung, wann immer sich die Gelegenheit ergibt.

Wie würden Sie mit einer solchen Situation umgehen?

Was würden Sie antworten auf "Codeformatierung ist totaler Mist" , "es ist wie Farben, manche Leute mögen es rot, andere blau, das ist es" , "es reduziert meine Freiheit" , "es macht Code komplizierter zu lesen ohne Mehrwert" usw. ?

Kommentare sind nicht für längere Diskussionen gedacht; Diese Konversation wurde in den Chat verschoben .
Vielleicht möchten Sie bearbeiten , um zu verdeutlichen, dass es keine zeitaufwändigen Probleme beim Bearbeiten des Codes oder beim Einchecken gibt (ich habe Probleme mit der Formatierung, die in meiner IDE nicht sinnvoll auf Standard gesetzt werden kann - ich bin nicht wirklich ein Fan von Hinzufügen Leerzeichen manuell, um den Formatierer/Stilprüfer glücklich zu machen). Die Antworten zeigen eindeutig, dass Sie zwischenmenschliche Probleme betrachten und nicht den eigentlichen Schmerzpunkt, den Sie eingeführt haben.
Eine Sache, die uns helfen könnte, Ihre Situation ein wenig besser zu verstehen, ist, ob Sie diese Entscheidung mit Ihrem Team besprochen haben, bevor sie umgesetzt wurde. Wenn Sie sagen „wir haben die obligatorische Codeformatierung eingeführt“, meinen Sie „wir, das Team, haben beschlossen, …“ oder „als Teammanager habe ich entschieden, dass unser Team …“? Hatten Sie konstruktive Gespräche mit Ihrem Team vor der Umsetzung der Neuformatierung, wenn ja, hat Ihr „Lead Developer“ damals Einwände erhoben? Wenn ja, wurden ihre Einwände gehört? Oder haben sie eines Tages einen Pull durchgeführt, nur um festzustellen, dass alles unter ihnen neu formatiert worden war?
Es ist interessant zu wissen, was genau mit Formatierung gemeint ist , wie detailliert ist die Formatierung? Während es absolut hilfreich ist, gleiche Einzüge, Position von geschweiften Klammern und dergleichen zu haben, ist es absoluter Blödsinn und überhaupt nicht hilfreich, in allen denkbaren Situationen wie Kommentaren oder Funktionen oder auch in der Mitte eine exakte Anzahl von Leerzeilen zu erzwingen von Funktionen. Richtig oder falsch zu sein ist für mich stark an solche Details gebunden. Können Sie Beispiele hinzufügen?
@puck OP verwendet Black, was eine sehr vernünftige Art ist, Code zu formatieren. Der Mitarbeiter ist schrecklich unvernünftig, wenn er sich über diesen Stil beschwert.
Wäre es tatsächlich eine Option, sich auf einen Codestil zu einigen und dann das Tool dazu zu bringen, diesen zu produzieren? Beginnen Sie vielleicht mit der schwarzen Standardeinstellung und besprechen Sie dann, ob Änderungen erforderlich sind (da es im Allgemeinen eine gute Idee ist, dasselbe wie alle anderen zu verwenden)?
Insbesondere @puck garantiert, dass Sie keine Commits von Bazilionen von Zeilen sehen, nur weil jemand einen anderen Formatierer für das gesamte Projekt ausgeführt hat und sich berechtigt fühlt, seine Meinung dazu zu haben

Antworten (26)

Meine Reaktion wäre ehrlich gesagt folgende:

Bob, ich weiß das Feedback zu schätzen, aber als Team haben wir entschieden, dass wir Black als unser obligatorisches Codeformatierungstool verwenden, und diese Entscheidung ist endgültig. Ich verstehe, dass es nicht Ihre persönliche Präferenz ist, aber ich fürchte, dass Sie lernen müssen, damit umzugehen.

Aber wenn ich mich auf eine Diskussion einlassen wollte?

"Codeformatierung ist totaler Bullshit"

Das ist kein sehr konstruktives Feedback, könnten Sie das konkretisieren?

"Es ist wie Farben, manche Leute mögen es rot, andere blau, das ist es"

Natürlich, aber die Standardisierung dieser „Farben“ ist sehr hilfreich, und wir mussten uns für eine entscheiden!

"Es reduziert meine Freiheit"

Das gilt auch für die Zustimmung, Code in derselben Sprache und Version dieser Sprache zu schreiben, aber können Sie sich das Chaos vorstellen, wenn wir es nicht tun würden?

"Es macht Code komplizierter zu lesen ohne Mehrwert"

Das ist nicht wahr. Wenn Sie Code in diesem Format nach einer Weile lesen, wird es überhaupt nicht komplizierter zu lesen sein - tatsächlich wird es einfacher zu lesen sein (Mehrwert dort), weil Sie nur einen Stil für das gesamte Projekt lernen müssen. Das bedeutet dann auch, dass Diffs für PRs viel besser lesbar sind, wir können andere Entwickler einbinden und sie schneller auf den neuesten Stand bringen, und Entwickler werden sich nicht darüber aufregen, welche Art von Formatierung in einer bestimmten Situation etwas hübscher aussehen könnte.

Um es klar zu sagen, wenn sein Feedback konstruktiv war - sagen Sie über das Format "Ich glaube nicht, dass Schwarz für uns aus x-, y- und z-Gründen hilfreich ist, da ein Großteil unseres Codes einem bc-Codierungsstil folgt, mit dem Schwarz schlecht umgeht, haben Sie stattdessen (ein anderes Tool) in Betracht gezogen", dann ist das ein ganz anderes Szenario. Dann sollten Sie sich bemühen, sich an einer Diskussion zu beteiligen, um seine Bedenken zu bestätigen, und mit ihm zusammenarbeiten, um sie anzusprechen.

but I'm afraid that if you want to stay in this teamIn meinem Kopf denke ich das vielleicht, aber ich würde es definitiv nicht so sagen, zumindest am Anfang. Dieser Typ scheint jemand zu sein, der schnell eskalieren könnte, und diese Formulierung wird ihn wahrscheinlich schneller eskalieren lassen. Ich würde eher so etwas verwenden wie: „Ich verstehe, dass es nicht Ihre persönliche Präferenz ist, aber ich musste eine Entscheidung für das Team treffen, und das ist es.“ Ich denke, das übergeordnete Ziel ist es, allen dabei zu helfen, die Vorteile zu verstehen und sich der Gemeinschaft anzuschließen. Wenn er weiter rebelliert, dann drehen Sie die Sprache auf.
@ JeffC Ja, das ist ein fairer Punkt. Ich meinte , dass es nicht verhandelbar ist, während er dort arbeitet, aber wenn ich es zurücklese, kommt das viel konfrontativer rüber, als ich es beabsichtigt hatte ...!
but as a team we've decided that we're using Black as our mandatory code formatting tool, das OP hat nie gesagt, dass dies eine Teamentscheidung war.
@Akavall "auf Vorschlag eines anderen Kollegen, den wir vorgestellt haben ..." Betonung von mir, und das lässt es für mich so klingen, als wäre es eine Teamentscheidung. Wenn dies nicht der Fall ist, dann (denke ich offensichtlich) lassen Sie einfach das "als Team"-Bit fallen. Der Rest der Antwort gilt immer noch.
„Wir haben eingeführt“ bedeutet nicht, dass die Entscheidung zur Einführung vom Team getroffen wurde, es hätte sein können, aber es musste nicht sein. Ich wäre vorsichtig mit der Behauptung, dass etwas eine Teamentscheidung war, wenn es das wirklich nicht war.
@Akavall Ich denke, es ist selbstverständlich, dass jede vorgeschlagene Antwort an die Situation angepasst werden sollte. Wie ich oben sagte, wenn es keine Teamentscheidung ist, lassen Sie das „als Team“-Bit fallen. Das sollte ziemlich offensichtlich sein, ebenso wie das Ändern des Namens des Kollegen, wenn es nicht "Bob" ist!
Was die Codeformatierung betrifft, so hängt es ganz davon ab, wie genau sie neu formatiert wird. Wenn zum Beispiel Funktionsdefinitionen automatisch wieder in den K&R-Stil geändert werden, hat er vielleicht Recht. Oder schreckliche Dinge tun, um in die 80-Zeichen-Grenze zu passen, oder Variablennamen abschneiden. Der Versuch herauszufinden, was ihm am standardisierten Format nicht gefällt, könnte für das OP nützlich sein.
@Graham Absolut. Wenn sein Feedback lautete: "Dies ändert automatisch die Funktionsdefinitionen zurück zu K&R, und das ist nicht hilfreich", dann ist das konstruktive Kritik, und Sie sollten mit ihm zusammenarbeiten, um zu sehen, ob es eine Problemumgehung oder vielleicht ein anderes Tool gibt, das für die Aufgabe besser geeignet wäre . Aber das ist eine Meile entfernt von den Argumenten "es ist Bulls ** t und reduziert meine Freiheit", die wir im OP sehen.
@berry120 Als jemand, der sehr lange nach MISRA-Regeln gespielt hat, stimme ich vollkommen zu. Freiheit beim Programmieren wird allgemein überschätzt. Ich mag es, Dinge zu sichern, die mir in den Fuß schießen könnten. :)
Ich habe mich entschieden, diese Antwort zu akzeptieren - ich kann nur eine akzeptieren, auch wenn es so viele andere mit guten Punkten gibt. Die Entscheidung für eine automatische, obligatorische Codeformatierung wurde mit Zustimmung der anderen Teammitglieder getroffen (außer einem, dann ...). Andere sind jedoch jünger. Ich habe das Wort "Lead Developer" verwendet, weil er das große Ganze des Projekts hat und Senior ist, aber ich bin auch ein Programmierer im Team ... Sicherlich macht meine Doppelrolle die Dinge manchmal schwieriger. Danke für die Hilfe Jungs!
Einige Black-spezifische Kommentare von mir könnten sein, dass ich nicht mag, wie alles formatiert wird - doppelte Anführungszeichen erzwingen, aber was auch immer auswählen -, aber ich werde das aus Gründen der Konsistenz aufgeben . Der nahezu vollständige Mangel an Konfigurierbarkeit bedeutet, dass Sie all diese kleinen Kämpfe über dies oder das nicht führen können, es ist ein Take-it-or-leave-it.
"Wir mussten uns für eine entscheiden!" lässt mich nur denken: "Ich bin farbenblind und Sie haben auf Farben standardisiert, die das Lesen erschweren, warum wurden meine Bedürfnisse nicht berücksichtigt? Warum wurde ich nicht konsultiert?" . Bei dieser Antwort geht es darum, den widerspenstigen Entwickler dazu zu bringen, sich anzupassen, wodurch eine bereits feindliche Umgebung noch feindlicher wird. Als Führungskraft geht es nicht darum, die Peitschenhiebe aufrechtzuerhalten, bis sich die Moral verbessert, sondern es geht darum, Barrieren zu beseitigen, die Menschen daran hindern, ihr Potenzial auszuschöpfen. Siehe Peopleware .

Wie würden Sie mit einer solchen Situation umgehen?

Nachdem Sie ihn nett getröstet haben, was Sie bereits getan haben, ist es an der Zeit, ihm nachdrücklich zu sagen, dass er sich darum kümmern soll . Es ist nicht der Kodex einer Person, sondern der des Unternehmens. Als Manager müssen Sie den Code so gut wie möglich von Ihrem Team wartbar machen und neue Ergänzungen, die Sie dem Team in der Zukunft hinzufügen.

"Code-Formatierung ist total b***$hit"

Da ich selbst Programmierer bin, werden in den Unternehmen, zu denen ich beigetragen habe, einige Formatierungsstandards durchgesetzt. Als leitender Entwickler würde ich eigentlich erwarten, dass sie ein Fan sind.

"Es ist wie Farben, manche Leute mögen es rot, andere blau, das ist es"

Als Ihr Manager mag ich Rot, kommen Sie damit klar.

"Es reduziert meine Freiheit"

Die Codeformatierung beeinträchtigt nicht die Freiheit, eine elegante Lösung zu erstellen. Ich rufe BS an, und Sie sollten es auch tun.

"Es macht Code komplizierter zu lesen ohne Mehrwert"

Ähm nein. Da frage ich mich tatsächlich, ob Ihr Hauptentwickler überhaupt ein Hauptentwickler ist....

Um es noch einmal zu wiederholen – Sie haben einen Standard gesetzt, als Manager oder als Team spielt es keine Rolle. Der Lead muss sich darauf einlassen oder vielleicht weiterziehen .

Kommentare sind nicht für längere Diskussionen gedacht; Diese Konversation wurde in den Chat verschoben .
@Eyal - Manchmal ist es die einzige Möglichkeit, ein hinteres Ende eines Esels zu sein, um mit einem Mitarbeiter zu sprechen, der der ganze Esel ist. (Mit anderen Worten ein Arsch für einen Arsch).
Für mich, wenn es nicht konkrete Kritik an der Formatierung gibt, die der Mitarbeiter nicht mag (Tabs vs. Leerzeichen, Anzahl der Leerzeichen pro Tabellierung [was nebenbei wirklich nur ein Problem ist, wenn Leerzeichen über Tabulatoren ausgewählt werden ], Klammerplatzierung, Linienfortsetzungsübungen usw.), dann sind sie nur um der Schwierigkeit willen schwierig. OP gab nicht an, dass der Mitarbeiter spezifische Kritik am aktuellen Tool hatte, sondern nur die Formatierung im Allgemeinen.
Eine rechthaberische Person ist äußerst nützlich, sobald sie bekehrt ist, und kann nutzlos werden, wenn sie dazu gezwungen wird . Es gibt Zeiten, in denen letzteres notwendig ist, aber es ist eine großartige Möglichkeit, Produktivität und Motivation zu zerstören. Ersteres ist meist konstruktiver – bei richtiger Umsetzung mittelfristig eine gute Investition für Team und Manager . Es ist möglich, jemanden zu vertreiben, der mit der richtigen Finesse und dem richtigen Verständnis bekehrt werden könnte und der ein starker Aktivposten wäre. Ich habe also Verständnis dafür, worauf diese Antwort hinausläuft, aber -1 dafür, dass ich die andere Seite dieses Kompromisses nicht einmal anerkenne.
Der Lead ist kein Teamplayer. Wir befinden uns immer wieder in Situationen, in denen wir Meinungsverschiedenheiten haben. Wenn Sie sich nicht an die Wünsche des Teams oder des Managements anpassen können, steht es Ihnen jederzeit frei, zu gehen.
Zunächst einmal sind Codeformatierung und Syntaxhervorhebung unterschiedliche Dinge und sollten separat behandelt werden. In den USA kann die Syntaxhervorhebung unter ADA-Anpassungen für kontrastreiche Anzeigeanforderungen abgedeckt werden. Zweitens können alle modernen IDEs personalisiert werden, um sie im Handumdrehen neu zu formatieren und hervorzuheben, und können den Code beim Commit auf den Unternehmensstandard umformatieren. Die beste Antwort hätte sein müssen, den Unternehmensstandard zu übernehmen UND Programmierern Unterstützung und Erlaubnis zu geben, die Codeanzeige zu personalisieren, um die Lesbarkeit auf ihren Workstations zu verbessern. Manchmal braucht ein Boss einen Arsch, aber diesmal nicht.
Ich habe abgelehnt, weil die Argumente in dieser Antwort die allgemeine Notwendigkeit eines konsistenten Codierungsstils ansprechen , während der Konflikt des OP über die Einführung eines bestimmten Tools aufgeworfen wurde . Ich denke, es ist nicht dasselbe: Ein Codierungsstil erfordert nicht unbedingt ein obligatorisches Tool.

Ich würde versuchen, ihn von den positiven Effekten einer einheitlichen Codeformatierung zu überzeugen. Git-Diffs werden viel einfacher zu verdauen, wenn Commit n und Commit n+1 die gleiche Formatierung haben. Die Wartbarkeit wird einfacher, vorausgesetzt, der Formatierer setzt bewährte Verfahren durch. Letztlich ist die Entwicklung von Unternehmenssoftware ein Mannschaftssport.

Wenn Ihr Code-Formatierer das Definieren von Regeln erlaubt, fragen Sie ihn, ob es bestimmte Regeln gibt, die er nicht mag, und erwägen Sie, diese mit Ihrem Team zu besprechen.

Der größte Vorteil von leichter verdaulichen Diffs besteht darin, dass Sie sich jetzt nur noch auf die tatsächlichen Codeunterschiede konzentrieren und Ihre begrenzte kognitive Aufmerksamkeit nicht für irrelevante Formatierungsänderungen aufwenden müssen. Oder, wenn es sich bei der Frage um Python handelt, Formatierungsänderungen, die möglicherweise irrelevant sind oder nicht. Unser Team hat damit begonnen, nur Formatierungs-Commits durchzuführen, gefolgt vom eigentlichen Code-Änderungs-Commit, um genau dieses Problem zu vermeiden.
+1, ich würde mit dir zusammenarbeiten. Diese Antwort ist die einzige, die nicht versucht, den Mitarbeiter davon zu überzeugen, dass die Umsetzung der richtige Weg ist, sondern dass das Ziel im Auge behalten werden soll. Indem er seinen Beitrag leistet, trägt er zur besten Lösung bei. Die Antworten wie Sag ihm, er soll es aufsaugen oder gehen, sind Müll. Das ist keine Führung.
„Git-Diffs werden viel einfacher zu verdauen, wenn Commit n und Commit n+1 dieselbe Formatierung haben.“ andererseits werden sie viel schwerer zu verdauen, wenn Sie gezwungen sind, die Einrückung eines großen Codeblocks zu ändern, nur um eine Bedingung hinzuzufügen oder zu entfernen.
Ich habe das Gefühl, dass dies die emotional intelligentere Antwort ist. Mein technischer Leiter hat mit unserem Manager über bestimmte Prozessstandards gekämpft, aber sie können sich normalerweise darauf einigen, es ein Vierteljahr lang auszuprobieren und das Gespräch fortzusetzen. Der Ansatz „Aufsaugen und damit umgehen“ ist nicht mein Ding, auch wenn der Mitarbeiter derjenige mit der schlechten Einstellung ist. Als Führungskraft muss man sich darüber erheben und darf sich nicht auf dieses Niveau herablassen.
+1 für die Frage, ob er Ideen zur Verbesserung hat. Es ist immer durchaus möglich, dass es legitime Gründe dafür gibt, dass ein bestimmter Codestandard nicht perfekt passt, also lohnt es sich manchmal, Änderungen in Betracht zu ziehen, aber nur, wenn es einen guten Grund gibt, dass es die Lesbarkeit und Struktur verbessert, wenn er jedoch an die Codeformatierung denkt hat keinen Nutzen, ich nehme an, er hat wahrscheinlich keine Vorschläge.
Das. Ich würde auch nach IDE-Unterstützung (nativ oder Plug-in) suchen, die Code in einen bestimmten Stil oder noch besser mehrere Stile umformatiert. Lass die Entwickler arbeiten, wie sie wollen. Der letzte Schritt vor dem Commit ist "Code auf Standard formatieren".
@PeterGreen, eines der schönen Dinge, die man mit Git machen kann, ist das Umschreiben des Verlaufs, sodass alles seit dem ersten Commit in Blackened-Form vorliegt . Tun Sie das und fügen Sie eine fortlaufende Durchsetzung hinzu, und Sie haben keine Änderungen ohne semantische Bedeutung in der Geschichte ... jemals.
@ivanivan Das wäre der zweite letzte Schritt. Der letzte Schritt ist natürlich, es zu testen, um sicherzustellen, dass es noch funktioniert.
@PeterGreen Sie würden die Formatierung und Ihre Änderung nicht im selben Commit festschreiben. Dafür sind Formatierungs-Commits da.

Wie würden Sie mit einer solchen Situation umgehen?

Ich würde versuchen, den widerspenstigen Entwicklerstandpunkt zu verstehen. Sie haben vielleicht gute Punkte zu machen, die ich ignoriere.

Hintergrund und unterstützende Erfahrung

Wir haben die automatische Formatierung vor einigen Jahren in unserer Codebasis implementiert und sie verursachte unzählige Probleme, teilweise aufgrund der Art und Weise, wie sie eingeführt wurde, aber hauptsächlich aufgrund der Art und Weise, wie sie unseren Workflow beeinflusste. Es verursachte so viel zusätzliche Arbeit beim Beheben von Zusammenführungskonflikten, dass wir am Ende viele Aspekte der automatischen Formatierung abschalteten, sodass nur Dinge automatisch korrigiert wurden, die nicht mehr Probleme verursachten, als sie lösten. Wir sind auch alle Einstellungen durchgegangen und haben nur diejenigen aufgenommen, denen alle zugestimmt haben.

Ein Problem bei der automatischen Formatierung besteht nicht nur darin, dass sie schlechte Formatierung „wegstandardisiert“, sondern auch gute Formatierung „wegstandardisiert“.

Ein automatischer Formatierer kann den Unterschied zwischen einem versehentlich hinzugefügten doppelten Leerzeichen und einem doppelten Leerzeichen, das hinzugefügt wurde, um ein Element in einer Zeile an einem Element einer anderen Zeile auszurichten, nicht erkennen. Diese visuelle Assoziation kann das Lesen des Codes viel einfacher machen, da es viel offensichtlicher sein kann, dass zwei Dinge in zwei Zeilen zusammenhängen.

Wenn Sie die automatische Formatierung implementieren möchten, müssen Sie das gesamte Team unterstützen.

Sie müssen die Formatierung global in einem Zweig anwenden und erst dann in diesem Zweig zusammenführen, wenn alle die Möglichkeit hatten, die Auswirkungen auf ihren Arbeitsablauf zu überprüfen, ihre Einwände zu erheben und sich auf eine Vorgehensweise zu einigen.

Die meisten Leute würden sich darauf verlassen, Leerzeichen automatisch von den Zeilenenden zu entfernen, nur wenige Leute würden wollen, dass ihre sorgfältigen manuellen Zeilentrennungen für die Lesbarkeit gedankenlos in das inkohärente Durcheinander aufgeteilt werden, das viele automatische Formatierungswerkzeuge erzeugen.

Mein Verdacht ist, dass dieser Entwickler verärgert ist, weil er stolz auf seine Arbeit ist, viel Zeit damit verbracht hat, seinen Code so lesbar und wartbar wie möglich zu machen, und diese automatische Neuformatierung alle seine sorgfältig ausgearbeiteten Formatierungen zerstört hat.

Auch wenn die Syntax von Python bereits einige Anforderungen an die Formatierung stellt, lässt sie dennoch viel Spielraum für den einzelnen Entwickler.

Zusamenfassend. Hören Sie auf die Einwände Ihrer Entwickler, vielleicht können Sie die Codebasis für alle verbessern. Wie PEP 8 – der Styleguide für Python-Code sagt

A Foolish Consistency ist der Hobgoblin der Kleingeister

Es steht aus gutem Grund ganz oben im Leitfaden .

In Anbetracht von jrhs Kommentar werden gelegentlich Leute ausgelacht, die das Programmieren als „mehr eine Kunst als eine Wissenschaft“ bezeichnen, aber ich bin anderer Meinung, wenn es um die Soft-Skill-Aspekte des Programmierens geht. Programme sprechen nicht nur mit dem Compiler/Interpreter, sie sprechen mit Programmierern, die diesen Code möglicherweise in Zukunft reparieren, verbessern oder warten müssen.

Um auf den Kommentar von VGR einzugehen : Ich glaube nicht, dass dies ein guter Ort ist, um Schwarz zu kritisieren . Ich habe dieses Tool nicht verwendet, aber beim Durchlesen der Beschreibung kann ich dort hauptsächlich gute Dinge sehen, insbesondere für die langfristige Wartung und Diffability (der Fluch komplexer Zusammenführungen).

Das hilft jedoch nicht, wenn das gesamte Team nicht auf eine so strenge und kompromisslose automatische Formatierung eingeht.

Das scheint der einzige Teil von PEP 8 zu sein, den die Leute ignorieren (ok, ok, das, und viele Leute haben herausgefunden, dass 80 Zeichen ein lächerlicher Anachronismus sind). Vertikal ausgerichtete ähnliche Teile von Linien sind überlegen. Bekämpfe mich.
80-Zeichen-Grenzen sind beliebt, nicht weil 30 Jahre alte Terminals sie hatten, sondern weil man so viel bequemer auf einen Blick sehen kann, was der Code macht, wenn man ihn nur mit den Augen scannt. Lange Zeilen beeinträchtigen die Lesbarkeit. Typografische Anleitungen für Text empfehlen normalerweise 45-70 Zeichen pro Zeile. Ich formatiere meine Kommentarblöcke oft auf eine Breite von etwa 60 Zeilen, weil ich finde, dass dies ein guter Punkt für die Lesbarkeit ist.
Diese Antwort berührt einige wichtige Probleme mit automatischen Formatierern, die selten angesprochen werden. Ich würde die sorgfältige Verwendung von nicht standardmäßigen Leerzeichen, die die Funktionalität nicht beeinträchtigen, als ein "verstecktes Merkmal" der Programmierung betrachten, und es kann manchmal wirklich hilfreich sein. Die einzigen Gegenargumente, die ich je dagegen gehört habe, sind mehr oder weniger "Nun, dann verbringen Sie mehr Zeit mit dem Erstellen Ihres Layouts als mit dem Formatieren", aber ich habe diese Art von Arbeit nie als Verschwendung empfunden, und ich auch nicht Stunden um Stunden damit verbringen...
... und ich denke, um ein konkretes Beispiel zu geben: 1) Würde jemand behaupten, dass eingerückte Listen mit Aufzählungszeichen in Stack Exchange nicht nützlich sind? 2) Würde es jeder vorziehen, wenn sie das aus Gründen der "Standardisierung" entfernen würden? 3) Hier ist ein Beispiel dafür, wie das aussehen würde. Ich schätze, ich würde Programmierern lieber die gleichen Ressourcen geben, die ein Autor haben würde (falls praktisch, weiß ich, dass Schriftgrößen und Fett / Kursiv problematisch wären); Entfernen Sie Leerzeichen am Ende der Zeile und erzwingen Sie die Einrückung von Tabs und Leerzeichen, sicher, aber ich bin kein Fan davon, Werkzeuge wegzunehmen, um Ideen gut zu präsentieren.
Während Sie einige gute Punkte ansprechen, habe ich in der Frage keine Erwähnung der automatischen Formatierung gesehen. Ich bin ein starker Befürworter von Codierungsstandards, aber ich verachte die automatische Formatierung, da das Ergebnis normalerweise schlecht ist. Wie und wo Standards eingehalten werden (z. B. wie man eine Linie am besten auflöst), ist eine Aufgabe, die am besten Menschen überlassen wird. mguijarr kann Codierungsstandards ohne die Verwendung automatischer Formatierung durchsetzen.
-1 Bei Workplace.SE geht es um den Umgang mit Menschen, nicht um technische Lösungen. Wasmachiens Antwort beschreibt zumindest, wie man die Technologie nutzt, um die Person zu überzeugen.
Ich verstehe nicht, wie Ihr Kommentar mir hilft, meine Antwort zu verbessern @Chris, meine Hauptpunkte sind menschenorientiert, meine technischen Punkte sind nur dazu da, den Kommunikationsbedarf zu verstärken.
@MarkBooth: Du schreibst über Whitespaces, Merging und Python Styleguides. Wenn dort menschenzentrierte Beratung enthalten ist, ertrinkt sie in technischen Details.
Die genaue Antwort steht ganz oben @Chris, sie ist kaum zu übersehen. Der Rest stützt Beweise aus persönlicher Erfahrung mit einer ähnlichen Situation wie der Entwickler, der „gemanagt“ wird.
@MarkBooth Eigentlich ist es kaum zu übersehen. Ihre Ratschläge sind zwei kleine Sätze in sehr langer Antwort. Aber andere scheinen zu denken, dass dies eine angemessene Antwort ist, deshalb belasse ich es dabei.
„Wenn Sie die automatische Formatierung implementieren wollen, müssen Sie das gesamte Team dafür einsetzen.“ - Das! Der Nutzen daraus entsteht, wenn jeder es tut. Möglicherweise möchten Sie, dass die Build-Toolchain die Quellen zur Kompilierzeit überprüft (und fehlschlägt, wenn sie nicht korrekt formatiert sind) oder dass Ihr Versionskontrolltool zur Push-Zeit überprüft.

Wenn ich eine Bäckerei besäße, möchte ich vielleicht, dass meine Bäcker Brote in Standardgröße verwenden. Es erleichtert zum Beispiel den Kauf von Tüten für das Brot. Ich kann einen konstanten Preis für die Brote haben, die ich mache.

Meine Bäcker könnten das Gefühl haben, dass dies ihre Kreativität einschränkt. Einige möchten vielleicht sehr kleine oder sehr große Brotlaibe backen.

Andere Bäcker haben vielleicht das Gefühl, dass sie ein viel größeres Brot bevorzugen.

Das bedeutet nicht, dass es keine triftigen Gründe gibt, einen Standard zu setzen.

Einige Bäcker möchten jedoch darauf hinweisen, dass die von mir gewünschte Laibgröße nicht in den Ofen passt. Ich wäre ein sehr vernünftiger Bäckereibesitzer, wenn ich auf diese Bäcker hören würde.

Ihr Teammitglied hält sich bereits an eine Vielzahl von Standards, die seine Kreativität einschränken und seinen Vorlieben widersprechen können. Dazu gehört die Arbeit im Team. Das bedeutet nicht, dass Sie keine Standards setzen sollten, aber es ist wahrscheinlich ratsam, konstruktives, nicht störendes Feedback zuzulassen und zu fördern.

Ich mag die Analogie. Betrachten Sie es für die zukünftige Verwendung als gestohlen!
Die Analogie geht mir etwas verloren, weil unformatierter Code genauso funktioniert wie formatierter, was man für Brot nicht sagen kann. Ein kleiner Laib erfüllt nicht die Aufgabe eines großen Laibs. Es ist wirklich schwer, dieses Konzept mit einem greifbaren, physischen Gut zu vergleichen.
@Geobits Ein runder Laib funktioniert genauso wie ein rechteckiger Laib, aber sie erfordern definitiv andere Taschen.
Ich denke, dies ist eine gute Antwort, da sie zeigt, dass der Grund für den Codeformatierungsstandard wahrscheinlich in der Frage fehlt. Oder zumindest herrscht Uneinigkeit über die Bedeutung des Standards.
@ user1234567890abcdef Ja, aber es sind immer noch verschiedene Brote, während das Endprodukt mit Code nicht anders ist. Die Codeformatierung ist eher so, als würden alle Ihre Bäcker ihre Arbeitsbereiche gleich anordnen, sodass sie austauschbar sind und jeder weiß, wo alles ist, wenn er an einem anderen Ort arbeiten muss. Auch keine perfekte Analogie, aber meiner Meinung nach näher.
@Geobits - Vor einigen Jahren gab es in einigen Apple-Programmen einen großen SSL-Fehler, der einen Fehler bei der Codeformatierung verursachte (dh zwei Codezeilen unter einer if-Anweisung schrieben). Das Beispiel ist vielleicht falsch, ich habe die genauen Details vergessen, aber es war ein ziemlich dummer Codierungsfehler. Der Punkt ist, dass Codestandards einen Zweck erfüllen.
Diese Analogie fällt dahingehend auseinander, dass von Programmierern ein hohes Maß an Originalität erwartet wird, während von Brot erwartet wird, dass es einheitlich ist. Es gibt Raum für Diskussionen, ob ein Programm zur Codeformatierung immer das Urteil eines menschlichen Programmierers außer Kraft setzen sollte (vorausgesetzt, dass der von Menschen erstellte Code einigermaßen konform mit dem Styleguide ist und dass Abweichungen ihre Berechtigung haben).
Ich mag keine Analogien in der Programmierung. Sie mögen hilfreich erscheinen, aber es ist normalerweise einfacher, über Programmieren zu sprechen, wenn Ihre Zielgruppe aus Programmierern besteht.
@Ramhound Stimmt, aber es wäre nur abgefangen worden, wenn eine falsche Formatierung zu einem Fehler geführt hätte. OP verwendet ein Tool, das falsch formatierten Code automatisch formatiert.
@Marc.2377 Das ist cool; Ich selbst mag Analogien beim Programmieren, wo es Sinn macht. Ich glaube nicht, dass es bei dieser Frage sehr um Programmierung geht, sondern um Standards bei der Arbeit
@PeteCon Gerne behilflich sein!
@Geobits Ich denke, die Funktion von Brot ist etwas schwer zu definieren, aber es funktioniert wohl gleich, obwohl Sie Recht haben, die Analogie reicht nicht wirklich weit. Ich denke jedoch, dass es für den Punkt dieser Frage steht
@200_success Ich stimme dem überhaupt nicht zu; der Code, den die Leute schreiben, verlangt überhaupt nicht nach Originalität; Für das Endprodukt kann es erforderlich sein, original zu sein. Kunden ist es egal, ob Ihr Quellcode original ist oder nicht
@Geobits Schlecht formatierter Code funktioniert möglicherweise, aber es ist in Zukunft schwieriger, damit zu arbeiten. Dasselbe gilt für unterschiedliche Brotgrößen. Eine talentierte Person kann möglicherweise mit einer kleineren Brotgröße arbeiten, aber wenn die Brotgrößen überall gleich bleiben, könnte eine größere Anzahl von Mitarbeitern daran arbeiten als ein paar hochqualifizierte Personen. Das Gleiche gilt für schlecht formatierten Code, da eine talentierte Person möglicherweise damit arbeiten kann, aber für das große Publikum ist es möglicherweise nicht so einfach, wenn jeder einen Standard hätte.
Das Backen von Liebesbroten in Standardgröße ist Akkordarbeit. Programmieren ist keine Akkordarbeit, es sei denn, Sie sind wirklich schlecht darin.
@Brian Ich fürchte, ich stimme nicht zu, dass Brotbacken "Akkordarbeit" ist. Ich bin mir auch nicht sicher, ob ich sehen kann, wie sich der Unterschied in der Art der Arbeit auf die Anwendbarkeit von Qualitätsstandards auswirkt.
@Donald Klingt wie nakedsecurity.sophos.com/2014/02/24/… Eigentlich hätte eine Neuformatierung geholfen, den Fehler zu finden, da es das zweite goto nach links unter das if verschoben hätte.
Ich bin mir bewusst, dass eine Neuformatierung es erfasst hätte.

"Codeformatierung ist totaler Bullshit"

Auch wenn dies einen Sinn hatte (und das nicht tut), deuten Schwarz-Weiß-Aussagen wie diese oft auf ein sehr unreifes Verständnis von:

  • wie man mit Entwicklertools umgeht und über deren Vor- und Nachteile ausgewogen und kontextreich (auch bekannt als professionell) diskutiert
  • wie man mit Teamarbeit umgeht

Wir brauchen professionelle und konstruktive Meinungen, keine fanatischen Axiome.

"Es ist wie Farben, manche Leute mögen es rot, andere blau, das ist es" / "es reduziert meine Freiheit"

Nein, es ist nicht wie Farben. Es geht um Lesbarkeit und um gemeinsame Standards .

Leute, die diese Beschwerde machen, gehen auf den egoistischen Weg und erkennen nicht den Mehrwert gemeinsamer Standards im Umgang mit Code und vor allem, den Code anderer Leute zu verstehen und sie dazu zu bringen, Ihren eigenen zu verstehen.

Die Tatsache, dass jeder seine eigenen Vorlieben hat, ist im Gegenteil genau der Grund, warum Sie Codierungsstandards haben sollten, von Kommentaren über Benennung bis hin zur Formatierung.

Das Opfern Ihrer "persönlichen Vorlieben" muss oft für ein größeres Wohl getan werden, gute Teamarbeit dreht sich alles um Kompromisse für das beste Ergebnis.

Stellen Sie sich vor, wenn:

  • Entwickler A hat seinen Standard
  • Entwickler B verwendet andere Formatierungsstandards
  • Neue "C"-Entwickler müssten Code in zwei verschiedenen Stilen lesen
  • D in drei ... und so weiter.

Es wird verwirrend und ermüdend, weil sich Ihr Gehirn an verschiedene Stile anpassen und ständig zwischen ihnen wechseln muss . Mit einem gemeinsamen Standard müssen Sie sich nur einmal anpassen . In gemeinsam genutzten Projekten setzen Sie aus sehr guten Gründen Standards durch, auch wenn es sich um Open Source-Projekte handelt .

Und was ist, wenn sie dieselbe Datei/Klasse bearbeiten? Wird es mit unterschiedlichen Codierungsstilen enden?

"Es macht Code komplizierter zu lesen ohne Mehrwert"

Ich denke, das, was ich oben gesagt habe, genügt als Antwort auf diesen völligen Unsinn.

Bearbeiten: Bitte schauen Sie sich auch die Antwort von @nitarshs an , sie gibt einen weiteren interessanten Blickwinkel aus gruppenpsychologischer Sicht, den ich interessant fand.

@NathanHughes nein, vielleicht schlechte Formulierung, ich bin kein englischer Muttersprachler. Ich wollte sagen "Leute, die Werkzeuge mit solcher Leichtigkeit zerschlagen".

Vielleicht hängt die Ursache des Problems nicht mit der Code-Formatierung zusammen, sondern mit etwas anderem ?

Meiner Erfahrung nach zeigt diese Situation deutlich, dass sich die abweichende Person nicht auf eine reife und rationale Weise ausgedrückt hat, unabhängig davon, ob sie richtig oder falsch liegt.

Ich bin mir nicht sicher, wie lange die betreffende Person schon bei Ihnen und dem Team ist, aber ich denke wirklich, dass Sie die Disposition der Person besser kennen sollten, um zu wissen, wie man mit solchen Situationen umgeht

Mir ist aufgefallen, dass sich auch rationale Menschen irrational verhalten, wenn sie sich über etwas nicht freuen. Sogar sie könnten sich der wahren Ursache ihrer Irritationen nicht bewusst sein.

Oder es ist einfach möglich, dass die Person von Natur aus unreif ist, in diesem Fall können Sie sie dann ignorieren, solange sie ihren Teil der Arbeit richtig macht.

Nehmen Sie sie vielleicht zu einem Drink/Abendessen mit und geben Sie ihnen etwas Pflege und Aufmerksamkeit. Du solltest dich ihnen öffnen und sie sich dir öffnen lassen. Versuchen Sie, Ihre Teamkollegen besser kennenzulernen, und lassen Sie sie Sie und den Rest des Teams besser kennen.

Sie haben möglicherweise eine sehr klare Vorstellung davon, was das andere Problem ist, und haben das Gefühl, dass es nicht an ihnen liegt, es anzusprechen.
Möglich. Ignorieren Sie in solchen Fällen einfach ihre Kommentare.

Hier geht es überhaupt nicht um Codeformatierung. Es ist die denkbar schlechteste Form von Mikromanagement. Immer wenn ein Commit durchgeführt wird, ändert ein dummer, geistloser Mikromanager den Code auf eine dumme Mikromanagement-Weise. Und dieser Entwickler ist sauer. (Es scheint, dass einige Leute das nicht verstanden haben - wenn ich "Mikromanager" sage, spreche ich über das Codeformatierungstool).

Ihr Gewinn und der Gewinn Ihrer Teams aus all dem ist nicht von Null zu unterscheiden. Ihr Verlust ist, dass Sie sich gestritten, Ihre Zeit verschwendet und jemanden verärgert haben, der bisher ein anständiger Entwickler war. Im besten Fall verlieren Sie seine Unterstützung und sein Engagement. Im schlimmsten Fall verlieren Sie ein wertvolles Teammitglied komplett.

Einfach das Tool ausschalten und fertig. Es hat und wird mehr Schaden anrichten, als es wert ist. Entscheiden Sie einfach: Wollen Sie zeigen, dass Sie die größten xxxx haben, um herumzuwinken, oder wollen Sie ein Team, das glücklich ist und seine Arbeit erledigt?

Eine konsistente Codeformatierung macht die Arbeit mit dem Code anderer Leute viel einfacher und macht diff einfacher. Hier geht es meiner Meinung nach um Professionalität und Teamarbeit, nicht um Mikromanagement. Nirgendwo steht, dass der Manager die Codeänderung vornimmt, es ist der Entwickler, der die Codeänderung vor dem Commit vornehmen sollte.
Ich denke, Sie machen mehrere ungerechtfertigte Annahmen: dass der Gewinn Null ist und dass die betreffende Person ein anständiger Entwickler war, dessen Engagement darauf zurückzuführen ist, dass er effizienter mit dem Rest des Teams zusammenarbeiten muss. Ich glaube nicht, dass beides richtig ist: Die meisten Projekte sehen Effizienzgewinne (z. B. erfordert Code-Review weniger Entschlüsselung des „kreativen“ Stils einer Person), und so wie es sich anhört, hat diese Person bereits Probleme mit der Arbeit in einem Team, und dies ist eine Manifestation von das eher als die Ursache.
Der Zweck des Code-Formatierungstools besteht darin, all die Kleinigkeiten zu eliminieren , die bei Code-Reviews anfallen. Hier gibt es keine Beteiligung von Mikromanagern; der Code-Formatierer erledigt seine Arbeit, und das war's.
@DanielRoseman Wenn Code-Reviewer bei der Codeformatierung pingelig sind, dann haben Sie ein echtes Problem. Und ich weiß nicht, ob ich das nicht klar genug ausgedrückt habe - das Codeformatierungstool ist der Mikromanager.
@gnasher729 nein, es ist eine Krücke für die Kollegen, die sich nicht die Mühe machen, sauber formatierten Code bereitzustellen. Wenn er es selbst "richtig" gemacht hätte, würde das Tool keine Änderungen vornehmen. Das tut er offensichtlich nicht. Dies ist also eine Möglichkeit, jede Diskussion zu verhindern, wenn jemand anderes sieht, dass die Änderungen all die schöne Formatierung rückgängig machen und die Codeüberprüfung verschmutzen.
Davon abgesehen könnte es sein, dass dieses Tool oder die Formatierung, die es ausführt, seine Arbeit schlecht macht. Aber das ist ein weiterer Punkt davon, ein solches Tool im Allgemeinen zu haben.
Ich kann unmöglich die Gesamtzeit aufzählen, die wir vor ein paar Jahren durch unseren verpfuschten Versuch verloren haben, die automatische Formatierung in unsere Legacy-Codebasis einzuführen. Selbst jetzt müssen wir Zeit damit verbringen, gelegentliche Merge-Konflikte aufgrund von Änderungen zu beheben, die während dieser Zeit vorgenommen wurden.
Formatierungsstandards mit Mikromanagement gleichzusetzen , ist auf so vielen Ebenen falsch.
Macht es Ihnen wirklich Spaß, Code manuell zu formatieren? Ich bin völlig abhängig von dem automatischen Formatierer geworden, den wir bei der Arbeit verwenden. Es ist eine einfache Aufgabe, die ich sehr gerne einem automatisierten Tool überlasse. Ich bin zu alt, um sicherzustellen, dass ich jede Quellzeile immer richtig formatiere.

Hier geht es nicht um Codeformatierung. Es geht darum, ein guter und effektiver Manager zu sein und eine Entscheidung durchzusetzen, die Sie bezüglich der Arbeitsweise des Teams getroffen haben – was, wie Sie gesagt haben, berücksichtigt wird und dem Team insgesamt zugute kommen dürfte.

Ich denke, das Problem lässt sich am besten veranschaulichen, indem die Einzelheiten aus Ihrer Frage entfernt werden:

Ich bin der Manager eines kleinen Teams von Entwicklern

-- Ich habe eine Entscheidung über ein Detail unserer Arbeitsweise getroffen --

Seitdem beschwert sich immer wieder ein Kollege und widerspricht dieser Entscheidung

Es ist ein Menschenproblem – der schwierige Teil des Managerdaseins. Es ist verlockend zu versuchen, den Inhalt der Beschwerden anzusprechen, weil sie vertrautes, angenehmes Gebiet sind und einigermaßen objektiv argumentiert werden können.

Aber widerstehen Sie dieser Versuchung, denn was Sie wirklich tun müssen, ist, diesem Teammitglied direkt und unmissverständlich zu sagen, dass es die Entscheidung akzeptieren und aufhören muss, darüber zu diskutieren.

Es ist persönlich, es ist unbequem, aber es gehört zum Job und ist das, was der Rest des Teams will und von Ihnen erwartet, das kann ich Ihnen versichern.

Darüber hinaus ist die Ursache wahrscheinlich auch ein Problem der Menschen. Während dieser Kollege gegen das Ergebnis der Änderung protestiert , kann er tatsächlich Einwände gegen die Art und Weise erheben, in der die Änderung vorgenommen wurde, oder gegen einen anderen Aspekt der Änderung. In diesem Fall ist die Formatierung nur ein Ablenkungsmanöver, das eigentliche Problem ist etwas anderes, und die Lösung besteht darin, die Dinge mit ihm zu besprechen, herauszufinden, was das wirkliche Problem ist, und es anzugehen.
Wenn Sie ein guter und effektiver Manager sind , sollte es nie notwendig sein, eine von Ihnen getroffene Entscheidung durchzusetzen .
Autoritäres Management mag in manchen Umgebungen effektiv sein, aber für Wissensarbeiter ist dies selten der Fall. Wenn Sie stolz auf Ihre Arbeit sind, dann kann Mikromanagement, das Überstimmen Ihrer Entscheidungen oder das Ignorieren Ihrer Meinung ein ernsthaftes Hindernis für Produktivität und Kreativität sein. Wenn die Scheiße den Lüfter trifft, sollte Ihr Manager derjenige sein, der den Regenschirm hält, während Sie ihn reparieren.
@MarkBooth stimme dem voll und ganz zu. Ich gehe hier davon aus, dass es sich um eine Entscheidung handelt, die unter Berücksichtigung der Meinung der Mehrheit des Teams getroffen wurde - offensichtlich, wenn mehr als nur dieser Einzelne dagegen ist, oder wenn nach dem praktischen Versuch seine Einwände sinnvoll sind und er Ihre / andere Teammitglieder, dann sollten Sie die Entscheidung natürlich noch einmal überdenken.
Ich bin mir nicht sicher. Angesichts des „auf Vorschlag eines anderen Kollegen“ und „ich finde Wert“ an anderer Stelle war meine Annahme, dass „wir haben uns vorgestellt“ das Royal we verwendet . Es ist ein übliches Merkmal des autoritären Managements, dass das Diktat eines einzelnen Managers in einen falschen oder ausgelutschten Konsens getarnt wird. "Erinnerst du dich nicht, wir haben uns alle beim letzten Treffen darauf geeinigt?", "Nein, du hast es vorgeschlagen, ich habe erklärt, warum das nicht funktionieren würde, und du hast gesagt, wir würden es später besprechen." Vielleicht werde ich in meinem Alter nur zynisch. *8')

Vor einigen Monaten haben wir auf Anregung eines anderen Kollegen eine obligatorische Codeformatierung in die Codebasis eingeführt

Seitdem beschwert sich immer wieder ein Kollege und widerspricht dieser Entscheidung

Das Kernproblem liegt nicht in der Entscheidung an sich, sondern darin, dass die Meinung dieses Kollegen bei einer Entscheidung, die ihn stark betrifft, nicht berücksichtigt wurde. Wurde dies richtig besprochen, mit allen Vor- und Nachteilen sorgfältig abgewogen (das gilt auch für den automatischen Teil der Vollstreckung), oder haben Sie sich einfach einseitig entschieden, „weil es mir persönlich gefällt“? Die Praxis zeigt, dass eine Person eine Gruppenentscheidung sehr viel eher verteidigt, wenn sie das Gefühl hat, dass ihre Meinung gehört und berücksichtigt wurde, auch wenn sie es am Ende nicht zur Entscheidung geschafft hat.

Realistischerweise verlassen Menschen Teams. Die Verwendung solcher Styler erleichtert es einer anderen Person, das Projekt in Zukunft aufzunehmen und den tatsächlichen Inhalt zu verstehen, anstatt die Redezeit zu verstehen, um die Formatierung zu verstehen.

Versuchen Sie, mit einer positiven Antwort darauf zu reagieren, dass Sie sie verwenden. Zum Beispiel „Code-Formatierer sind bs“, „Nun, es kann einfacher sein, einfache Fehler im Code zu finden, wenn Sie wissen, wie er aussehen sollte“ usw. Noch besser, wenn sie direkt für Ihr Projekt/Team relevant sein können.

Wenn es mehr als ein Teammitglied wäre, hätte ich vorgeschlagen, ein Meeting abzuhalten, in dem erklärt wird, warum dieses Formatierungstool verwendet wird, welchen Nutzen es bringt und warum es so wichtig ist, dass Ihre Entwickler es verwenden. Menschen mögen keine Veränderung, wenn sie die Gründe dafür nicht verstehen.

Ich stimme zu. Richtiger Code sollte richtig aussehen und falscher Code sollte falsch aussehen. Und die Kraft dabei ist, dass das menschliche Gehirn als Musterfindungs- und Bedeutungserzeugungsmaschine die Codemuster, die es immer wieder sieht, analysiert und dann ein „Gefühl“ aufbaut, wenn etwas nicht richtig aussieht all dies geschieht ohne bewusste Anstrengung. Schließlich werden Fehler abgefangen oder gar nicht geschrieben, weil „falscher Code falsch aussieht“. Wenn ein Team nicht konsistent ist, werden jedes einzelne Mitglied falsche „Warnungen“ über falschen Code erhalten, nur um festzustellen, dass es sich nur um einen Unterschied in der Formatierung handelt. Das ist schlecht.
@CodeSeeker: Gut gesagt.

Weit entfernt von einer vollständigen Antwort, aber es gibt hier einen Punkt, der mir auffällt. Die Codeformatierung in Ihren Commits muss in keiner Weise die gleiche Codeformatierung sein, die in der IDE eines Entwicklers verwendet wird, während sie an einer lokalen Kopie des Repositorys arbeiten. Ich weiß nicht, ob ich jemals an einem Gemeinschaftsprojekt gearbeitet habe, bei dem nicht jeder Entwickler seinen Code so formatiert hatte, wie er es wollte. Das Anwenden der Formatierung beim Festschreiben ist einfach genug, um über Git-Hooks eingerichtet zu werden .

Stimme dieser Antwort voll und ganz zu. Pre-Commit-Hooks sind die Antwort. Andere VC-Tools haben ähnliche Steuerelemente. Die grundlegendste Verwendung dafür besteht darin, konsistente Zeilenenden in gemischten Entwicklungsumgebungen sicherzustellen. Der Entwickler kann tun, was er will, aber der Commit-Hook sorgt für „saubere“ Commits.
Das ist genau das, was ich dachte, wie ich Code formatiere, unterscheidet sich sehr von der Art und Weise, wie die anderen Entwickler in meiner Gruppe ihren formatieren. Wenn sie meinen Code in ihrer IDE öffnen (wir verwenden im Allgemeinen VS Code für Websachen und VS Studio für den Desktop), wird er in ihrem Format angezeigt. Zugegeben, wir schreiben kein Python, was eine strenge Handhabung der Einrückungen erfordert, aber es gibt keinen Grund, wie ein bestimmter Entwickler seinen Code formatiert hat, sollte einen Unterschied machen, wie andere seinen Code formatieren.
@delliottg: Ja, und die Verwendung eines solchen automatischen Formatierers könnte das Python-Problem lösen, bei dem Code, der von jemandem geschrieben wurde, der wörtliche Tabulatoren für Einrückungen verwendet, in einem Editor mit unterschiedlichem Tabulatorabstand auseinanderfällt.
Und genau das haben wir, einer unserer erfahrenen Entwickler verwendet gerne Leerzeichen für Einzüge, ich bevorzuge Tabulatoren, aber ich formatiere seinen Code nicht neu, um die Leerzeichen zu entfernen, und er ändert meine Tabulatoren nicht in Leerzeichen. (Denken Sie daran, dass wir Python oder andere mit Einrückungen formatierte Sprachen nicht verwenden). Wir streiten gelegentlich darüber, aber es ist für keinen von uns eine so große Sache, dass wir es mit einem Linter oder einem anderen Werkzeug durchsetzen wollen.
Ich bin mir nicht sicher, ob Leute, die dies vorschlagen, tatsächlich Entwickler sind, die mit Code arbeiten. Die automatische Neuformatierung macht Merges, Linenumbers und Diffs zu einem Alptraum.

Ich finde einen großen Unterschied zwischen dem Beharren auf gut formatiertem Code und einem Auto-Formatierer, der beim Einchecken auferlegt wird.

Bei meiner Arbeit haben wir eine Art Code-Formatierungs-Mandat, das in die IDE geladen wird, aber wenn es wirklich schlecht läuft, können wir wirklich etwas dagegen tun, weil nichts versuchen wird, es zum Commit-Zeitpunkt erneut anzuwenden .

Ich bin bereit zu glauben, dass Sie ein echtes Problem damit haben, dass ein leitender Entwickler Dinge absichtlich so macht, dass sie schwerer zu verstehen sind, aber es ist durchaus möglich, dass der Autoformatierer hier handformatierte Blöcke durcheinander bringt, wo die Die Sprache wurde in etwas anderes verbogen und benötigt daher ein anderes Format, das der Struktur entspricht, die sie tatsächlich hat, und nicht dem, was der Parser glaubt.

Diese Fälle sind von Ihrem Beitrag nicht zu unterscheiden. Je nachdem, was vor sich geht, können Sie möglicherweise mit Ihren anderen Entwicklern sprechen und herausfinden, um welche es sich handelt. Hüten Sie sich jedoch vor der Einstellung "Ich glaube, es ist besser, weil der Chef es tut"; es wird nicht zu dir gesprochen, aber ich habe es schon früher so fallen sehen.

Es ist tatsächlich möglich, dass jeder ein Problem damit hat, und sie alle lassen diesen Typen zum Sprecher werden. Vielleicht kannst du es herausfinden.

Aber wenn Sie nach Ihrer Sorgfaltspflicht feststellen, dass er auf einem Machttrip ist, ist es an der Zeit, ihn loszuwerden.

Und wenn Sie feststellen, dass Sie derjenige auf einem Machttrip sind, sollten Sie darüber nachdenken, wie sich das in Zukunft auf die Leistung Ihres Teams auswirken wird.

Sie führen ein offenes Gespräch darüber, was das Wort „Professionalität“ bedeutet.

Ihr "Hauptentwickler" benimmt sich wie ein schmollendes Kind. Er/sie mag über die technischen Fähigkeiten eines Leads verfügen, ihm fehlen jedoch offensichtlich die beruflichen Fähigkeiten eines Leads. Es geht um mehr als nur das Schreiben von Code: Technische Fähigkeiten sind eine notwendige , aber nicht hinreichende Voraussetzung für diese Position. Ein Lead zu sein bedeutet, zumindest für mich, zu verstehen, dass es nicht um Sie geht . Das bedeutet nicht , dass Sie nicht verhandeln und sich für sich selbst einsetzen, es bedeutet , dass Sie sich nicht über Dinge ärgern, die Best Practices der Branche sind, selbst wenn Sie sie privat für Bullshit halten (Sieh dich an, JIRA ).

Ich würde damit beginnen, dass er/sie diplomatisch darüber hinwegkommen muss, dann dazu übergehen, es undiplomatisch zu sagen, und dann zu einem PIP übergehen. Sie haben bereits zu viel Ihrer wertvollen Zeit mit dem Wutanfall eines anderen verschwendet.

BEARBEITEN basierend auf der Konversation in den Kommentaren

Ein Kommentator weist zu Recht darauf hin, dass die Autorität des technischen Leiters möglicherweise auf unfaire Weise untergraben wurde, was zu Verstimmungen geführt hat. Obwohl ich sicherlich zustimme, dass dies der Fall sein könnte, ist es eine unprofessionelle und inakzeptable Reaktion auf die Situation, in der Öffentlichkeit über das Tool zu meckern . Unterminiert zu werden sollte direkt und privat angesprochen werden .

Ich kenne einige Programmierer, die die Notwendigkeit konsistenter Codierungsstandards nicht verstehen konnten. Wenn sie das nicht verstehen können, garantiere ich, dass es andere wichtige Dinge beim Programmieren geben wird, die sie nicht verstehen können. Es gibt keine Heilung dafür.
@Ed Plunkett: Aber es gibt einen Unterschied zwischen konsistent und gut. Ich kenne Leute, die eine perfekt konsistente Codeformatierung anwenden, die ihren Code fast unlesbar macht - jedenfalls für mich. Vielleicht arbeiten ihre Gehirne anders?
@jamesqf „Konsistent“ in dem Sinne, dass das gesamte Team es auf die gleiche Weise tut, vorzugsweise auf eine Weise (PEP3 im Fall von OP), die in der Branche üblich und für neue Teammitglieder leicht verständlich ist. In C# verwenden wir in meinem Team die VS-Standardwerte. Nicht mein persönlicher Favorit, aber sehr klar und sehr nah am Universellen – was viel besser ist, als nur meinen privaten ästhetischen Ansprüchen gerecht zu werden.
@jamesqf Die „Gehirn funktioniert anders“-Typen sind diejenigen mit den unheilbaren Verständnisproblemen, die ich erwähnt habe. Sie genießen es, schwierig zu sein. In einer Branche voller, taktvoller, „nicht-neurotypischer“ Menschen gibt es einige davon.
PEP 3 ist Richtlinien für den Umgang mit Fehlerberichten @EdPlunkett, ich glaube, Sie meinten PEP 8 , und Schwarz geht weit über PEP 8 hinaus.
@MarkBooth. Richtig, das war ein Tippfehler. Danke. Mein Punkt war, dass OP keine seltsamen willkürlichen Formatierungskonventionen erzwingt.
Nachdem ich mir Schwarz angesehen habe, ist die Formatierung, die es erzwingt, ziemlich seltsam @EdPlunkett. Ich habe sicherlich noch nie jemanden gesehen, der Code von Hand geschrieben hat, der dem Format ähnelt, das er generiert, und ich unterstütze ein Produkt, das einen eingebetteten Python-Interpreter enthält - also sehe ich alle möglichen seltsamen und wunderbaren benutzergenerierten Pythons. Theoretisch befürworte ich tatsächlich die Änderungen, die es vornimmt, aber Sie können nicht erwarten, dass es allen auf Anhieb gefällt, ohne die Möglichkeit zu haben, sich an die potenziellen Vorteile zu gewöhnen.
@MarkBooth Bei dem Argument geht es nicht um die Vorzüge dieses bestimmten Formats (oder dessen Fehlen), der OPs-Mitarbeiter ist gegen eine Standardformatierung, Punkt. Ich bin in vielerlei Hinsicht kein großer Fan von PEP 8, aber nun, es geht nicht um mich. Streitigkeiten darüber, welcher Formatierungsstil besser ist, sind für die Bar (ich genieße sie so sehr wie die nächste rechthaberische Sauerei), nicht für den Sitzungssaal.
Dies sollte wahrscheinlich in The Workplace Chat @JaredSmith verschoben werden, aber mein Punkt war, dass die Verwendung von Schwarz keine unumstrittene Entscheidung ist, ich kann sehen, was es erzwingt, einige Leute in die falsche Richtung zu reiben. Es hätte sicherlich nicht ohne das Buy-in des leitenden Entwicklers für das Projekt gemacht werden dürfen. Das OP hätte sich überhaupt nie in diese Position bringen dürfen.
@MarkBooth stimme dir bezüglich des Chats zu. Ich bin mir nicht sicher (nachdem ich Ihre Antwort gelesen habe), dass ich Ihnen nicht zustimme, wir haben nicht genügend Informationen, um dies zu beurteilen. Aber ich habe definitiv mit Entwicklern zusammengearbeitet, die trotz Androhung einer Vertragskündigung auf ihrer eigenen seltsamen unleserlichen Formatierung bestanden, weil, ich zitiere, "es ist, was ich gewohnt bin und ich nicht ändern möchte". Wenn der Entwickler berechtigte Einwände hat, dann gibt es einen Weg, sie vorzubringen. Aber nach meiner Lektüre des Tons der Frage klingt es viel mehr nach dem Zisch-Anfall-Fall als nach dem sorgfältig überlegten.
Meine Vermutung ist, dass der „Hissy-Fit“ erst auftrat, nachdem die Autorität des leitenden Entwicklers bereits unangemessen untergraben worden war. Denken Sie daran, dass wir dies nur aus der Sicht des OP hören, also können wir das Beste, was wir tun können, zwischen den Zeilen lesen. Jetzt geht es um Schadensbegrenzung, und das bedeutet, zuzuhören, ihnen nicht vorzuschreiben, was „Professionalität“ ist, oder über Disziplinarmaßnahmen zu sprechen, wie es diese Antwort zu tun scheint. Apropos, Sie möchten vielleicht definieren, was Sie mit "weiter zu einem PIP" meinen. Ich nehme an, Sie meinen "Professional Improvement Plan", aber ich bin mir nicht sicher.
@MarkBooth ja, Leistungsverbesserungsplan. Und nein, mir ist jetzt klar, dass ich Ihnen nicht zustimme: Selbst wenn die Autorität unangemessen unterminiert wurde (und Sie haben Recht, das kann durchaus der Fall gewesen sein), rufen Sie das direkt und unter vier Augen an . Sie tun es nicht, indem Sie in der Öffentlichkeit über das Tool schimpfen. Ich nenne Schwindel.
@EdPlunkett Einschließlich des Abschnitts von PEP 8 (ich nehme an, Sie meinten 8), in dem es heißt: "Eine dumme Konsistenz ist der Hobgoblin der kleinen Köpfe"?
@immibis Danke. Dieser Kommentar destilliert eine ganze Weltanschauung so perfekt.

Letztendlich haben Sie als Manager, wie andere Antworten gesagt haben, die Befugnis, einfach einen Codestil durchzusetzen, und wenn es jemandem nicht gefällt, kann er kündigen. Dies ist jedoch wahrscheinlich nicht gut für die Moral oder das Engagement, und ein Mitarbeiter, der seinen runden Code widerwillig in einen quadratischen Stil zwingt, ist wahrscheinlich nicht glücklich oder produktiv.

Zu diesem Zweck wäre Ihre beste Vorgehensweise wahrscheinlich, sie davon zu überzeugen, dass ein konsistenter Stil in einer Codebasis von Vorteil ist. Einige Antworten haben bereits einige Punkte präsentiert, aber es gibt Artikel und sogar ganze Bücher, die dafür sprechen. Sie haben Recht, dass es wie bei Farben ist – jeder hat einen Favoriten, aber wenn jeder UI-Entwickler, der an einem Projekt arbeitet, einfach seine Lieblingsfarbe für das Design auswählt, würde das Endprodukt überhaupt nicht gut aussehen.

Ein paar gute Artikel, die ich gerade mit einer schnellen Suche gefunden habe:

Ich gehe davon aus, dass Ihre Darstellungen der Kommentare Ihres leitenden Entwicklers korrekt sind.

Dies sind nicht die Kommentare eines kompetenten Hauptentwicklers. Das sage ich als erfahrener Software- und Manager von Software-Ingenieuren.

Das Feedback ist unkonstruktiv und höchst ungenau. Ein leitender Entwickler, der den Wert von Formatierungsstandards nicht versteht, ist ein leitender Entwickler, der die Dynamik von Collaborative Engineering nicht versteht.

Es ist durchaus möglich, dass sie berechtigte und umsetzbare Bedenken haben, und ich würde von dieser Perspektive ausgehen. Sie sind ihr Manager; ihnen helfen, ihre Arbeit gut zu machen.

Rufen Sie sie zuerst privat wegen ihres beschissenen Feedbacks an Sie an. Sie machen ihre Arbeit schlecht, wenn sie nur kvetchen.

Zeigen Sie als Nächstes, dass Sie offen für umsetzbares Feedback sind, wie Sie die Implementierung von Codierungsstandards verbessern können, falls Ihr Entwickler welche hat. Wenn sie Zeit brauchen, um herauszufinden, wie sie das am besten artikulieren können, geben Sie ihnen Zeit.

Wenn sie nichts Bestimmtes haben, dann sagen Sie ihnen, sie sollen mit dem Programm anfangen und aufhören zu meckern. Es ist nicht nur unproduktiv. Das schadet dem Team.

Sie sollten auch anfangen, auf ihre Leistung als Führungskraft im Team im Allgemeinen zu achten. Führen sie die anderen Teammitglieder tatsächlich an oder sind sie einfach die Person, die schon am längsten dabei ist? Solche Leute können die Produktivität eines Teams wirklich untergraben, wenn sie nur als Torwächter zum Wachstum fungieren (was diese Person gerade tut).

Ich würde vorschlagen, dass die wahrscheinlichste Erklärung ein Manager auf einem Machttrip ist, der das, was der Teamleiter sagt, in einem möglichst negativen Licht darstellt. Zum Beispiel finde ich es sehr unwahrscheinlich, dass ein Entwickler sagt „Codeformatierung ist Unsinn“, weil Sie eigentlich keine andere Wahl haben, als ihn irgendwie zu formatieren, aber dass jemand sagt „Codeformatierungstools sind Unsinn“, das kann ich glauben.
Sicherlich möglich, aber ich habe definitiv gehört, wie leitende Ingenieure die dümmsten Dinge über "ihre Freiheit wird eingeschränkt" sagen, wenn sie wirklich meinen: "Ich kann mich nicht darum kümmern, die anderen Leute zu berücksichtigen, die sich diesen Code ansehen werden."

Aus pragmatischer Sicht liebe ich die Codeformatierung, einfach weil sie den Vergleich von Code so viel einfacher macht. Es wird auch Pushs viel einfacher machen, denn wenn jeder denselben Code-Formatierer verwendet, führt das Hinzufügen einer dummen, belanglosen Änderung zu einer Datei im Prinzip nicht dazu, dass Git denkt, dass sich der Code geändert hat.

Persönlich bin ich nicht verrückt nach dem Aussehen des Codes, aber die oben beschriebenen Vorteile helfen mir mehr als, darüber hinwegzusehen.

-1 Dies beantwortet die Frage nicht. Ja, Codeformatierung ist nett, aber OP weiß das bereits.

Viele andere Antworten diskutieren, ob sich die Codeformatierung lohnt oder nicht. Das ist für diese Frage völlig irrelevant.

Hier geht es um Kommunikation, nicht darum, ihn davon zu überzeugen, dass standardisierte Codeformatierung großartig ist. Geh einen Schritt zurück. Was Sie kommunizieren müssen, ist:

  • Was Sie erreichen möchten.*
  • Wie Sie den Erfolg messen möchten.

Diese zusätzlichen Informationen ermöglichen es ihnen, die Dinge aus Ihrer Sicht zu sehen, was oft ausreicht, um sie zu beruhigen. Der zweite Teil (Erfolgsmessung) ist notwendig, um zu zeigen, dass Sie sich wirklich Gedanken gemacht haben, und erleichtert es ihnen, Ihnen zu vertrauen. Es ermöglicht ihnen auch, Alternativen oder Änderungen an der Richtlinie zu finden, die Ihre und ihre Anforderungen erfüllen.

Wenn dies fehlschlägt, gibt es zwei Hauptmöglichkeiten, um mit Mitarbeitern umzugehen, die mit einer Richtlinienänderung nicht einverstanden sind:

  • Höre ihnen zu. Sie sind bezahlte Fachleute und ihre Bedenken sind möglicherweise berechtigter als Sie denken.
  • Halt sie still. „Das ist die Entscheidung. Ich weiß, dass sie dir nicht gefällt, und ich habe deine Bedenken gehört, aber jetzt musst du sie akzeptieren und mit dem Team zusammenarbeiten.“

*Hier geht es nicht um eine Aufzählung von Vorteilen, sondern um Ihre Motivation, die Veränderung umzusetzen. Vielleicht möchten Sie das Team stärken, und deshalb haben Sie das Team über Codestandards und Formatierung entscheiden lassen. Vielleicht haben Sie gerade einen Vorschlag von oben umgesetzt. Vielleicht planen Sie später mehrere Automatisierungs- und/oder Analyseänderungen, die von einer standardisierten Formatierung profitieren. Vielleicht möchten Sie eine standardisierte Formatierung verwenden, um Ihr Team besser an die höheren Stellen zu verkaufen. Vielleicht haben Sie die standardisierte Formatierung vorangetrieben, einfach weil Sie sie mögen.

Codeformatierung ist totaler Blödsinn

Dies kann leicht widerlegt werden, indem Sie einen Beispielcode nehmen (der dem Entwickler unbekannt ist), alle Zeilenumbrüche und Tabulatoren entfernen und mehrere Leerzeichen auf einzelne Leerzeichen reduzieren und den Mitarbeiter bitten, Ihnen zu sagen, was der Code bewirkt.

Es ist wie mit Farben, manche Leute mögen es rot, andere blau, das war's

Ja. Dies ist bei so ziemlich jedem Programmierstreit der Fall. Tabulatoren vs. Leerzeichen, C-Klammern oder ägyptische Klammern, ... Aber die Antwort ist immer die gleiche: Die einen fahren gerne links, die anderen gerne rechts. Beides ist in Ordnung, aber beides gleichzeitig zuzulassen führt zum Wahnsinn.

Oder, wenn Sie seine Analogie wirklich gegen ihn verwenden wollen: Aber die Verwendung von Blau und Rot zusammen ergibt Lila, was bedeutet, dass niemand bekommt, was er will.

Es wurde eine Exekutiventscheidung getroffen, dieses Format auszuwählen. Ihr Mitarbeiter ist nicht befugt, diese Diskussion außer Kraft zu setzen. Ende der Geschichte. Ich würde diese Fragestellung nicht weiter verschweigen.
Ich bin immer offen für konstruktives Feedback, aber das Argument Ihres Mitarbeiters ist hartnäckig, es ist nicht konstruktiv. Lass sie es nicht zu einem Wettbewerb machen, der sturste zu sein. Selbst wenn Sie gewinnen, signalisieren Sie Ihren Mitarbeitern, dass Sturheit ein akzeptables Mittel ist, um Meinungsverschiedenheiten auszudrücken.

Das bedeutet nicht, dass Sie ihm nicht helfen können, wenn es nur eine Frage der Unerfahrenheit ist. Vielleicht finden Sie einen automatischen Formatierer, damit er sein eigenes Format eingeben und konvertieren kann.

Ich habe den Leuten, die ich leite, gesagt, dass ich mich nicht um die Lesbarkeit ihres Codes kümmere, bevor sie ihn einchecken. Ich erwarte nicht, dass sie den Styleguide in jeder Sekunde vollständig einhalten. Solange der Code bereinigt wird, bevor er in den Zweig gemergt wird, ist das akzeptabel. Ich beginne oft mit schnellem und schmutzigem Code und bereinige ihn erst, wenn ich ihn zum Laufen gebracht habe. Manche Leute arbeiten so, und das ist in Ordnung, solange sie am Ende nicht die erforderliche Bereinigung überspringen.

es reduziert meine Freiheit

Niemand hat die Freiheit zu tun, was er will. Die Bezahlung der Mitarbeiter schränkt auch die Freiheit des Unternehmens ein.

Der Aufwand, der erforderlich ist, um den Code von Anfang an zu formatieren, zahlt sich aus, wenn jemand anderes seinen Code lesen muss.

Angesichts der Bemerkungen dieses Mitarbeiters vermute ich, dass er sich wahrscheinlich über die Codeformatierung oder Namenskonventionen anderer Leute beschwert hat. Weisen Sie darauf hin, dass andere über seine Formatierung und Benennung genauso denken werden. Einheitlichkeit bedeutet, dass jeder den Code aller lesen kann, unabhängig davon, ob es die persönlichen Vorlieben aller sind.

es macht Code komplizierter zu lesen ohne Mehrwert

Es ist jetzt schwieriger für ihn zu lesen, weil er es nicht gewohnt ist. Je mehr er sich der Veränderung widersetzt, desto länger wird er damit kämpfen. Die Entscheidung ist gefallen, es passiert, Ende der Geschichte.

Ich würde mich auf den Punkt konzentrieren, dass der Mitarbeiter über das neue Format informiert wurde und nun erwartet wird, dass es sich daran hält. Wenn sie sich nicht daran halten (oder sich nicht ernsthaft anstrengen), fallen alle Verzögerungen, die durch die Ablehnung ihrer Pull-Requests verursacht werden, direkt auf ihre Schultern.

Code-Merge-Anfragen müssen mit dem Tool formatiert werden, sonst können sie nicht zur Software hinzugefügt werden.

Wenn Sie „kann nicht“ sagen, meinen Sie damit, dass es nicht erlaubt oder nicht möglich ist (z. B. wird ein Prüfer die Anfrage immer ablehnen)?

Wenn es letzteres ist, ist das der Stick, den Sie brauchen. Wenn der Entwickler die Formatierungsregeln nicht befolgt, werden seine Anfragen nicht akzeptiert und alle daraus resultierenden Verzögerungen gehen zu seinen Lasten, was zu einer schlechten Leistungsbewertung führt.

Wenn es ersteres ist, dann verlassen Sie sich wirklich darauf, dass jeder freiwillig an dem System teilnimmt, das nur funktioniert, wenn alle dies tun. Sie haben es gerade mit jemandem zu tun, der ausharrt. Es ist möglich, dass er gezielt ausharrt, weil er weiß, dass Sie es nicht erzwingen, sondern nur fragen.

Sie glauben also blind, was OP Ihnen gesagt hat. Er versagt eindeutig als Manager und möchte hier Unterstützung, daher würde ich nicht glauben, dass eines seiner Zitate korrekt ist.
@gnasher729: Es ist keine Glaubenssache. SE hat kein Format, das es der Gegenpartei ermöglicht, ihre Seite mitzuteilen, und uns dann zwischen zwei gegnerischen Parteien schlichten lässt. Das Q&A-Format bindet uns von Natur aus an den Inhalt der gestellten Frage. Ich kann die Frage nur so beantworten, wie sie gestellt wurde, ihre Anwendbarkeit im wirklichen Leben hängt ganz davon ab, wie sehr die Frage selbst im wirklichen Leben begründet ist. Obwohl allgemein erwartet, gibt es keinen wirklichen Schutz für fiktive oder falsch dargestellte Situationen.
@gnasher729: Zweitens, nach welchem ​​Maß bewertest du OP als „als Manager versagt“? Sie sind sich nicht sicher, wie sie einen Mitarbeiter ansprechen sollen, der sich nach OPs Erfahrung ohne wirklichen Grund einer Teamkonvention widersetzt, außer der mangelnden Bereitschaft, sich anzupassen. Inwiefern ist der Versuch, das Problem zu lösen und zusätzliche Erkenntnisse zu gewinnen, gleichbedeutend mit einem Versagen als Manager? Gehen Sie zu allen geposteten Fragen zu SO / SE und weisen Sie auf die Inkompetenz jedes OP hin, weil sie die Antwort auf ihre Frage nicht kennen?

Sie sind ein Manager, also versuchen wir, ihn zu managen (und das), schimpfen Sie ihn nicht einfach ab oder sehen Sie ihn als Problem an:

„John, meine Verantwortung besteht darin, dies für alle so einfach wie möglich zu machen, und für zukünftige Mitarbeiter, nicht nur für einige der Menschen hier heute.“

„Wenn sich die meisten Entwickler den Code ansehen, ist es schneller, wenn sie einige Dinge als selbstverständlich ansehen können, wie zum Beispiel die Art und Weise, wie der Code erstellt wird, und die Art und Weise, wie einige Dinge standardisiert werden. Wenn es jemals notwendig ist, dass jemand den Code [ External Code-Audit? Haftung? Due Diligence?] , es ist besser, wenn es standardisiert ist. Sie haben Recht, einige mögen Blau und andere mögen Rot, und außerhalb der Arbeit können Sie und ich beide so programmieren, wie wir wollen. Aber während wir' Um Code zu schreiben, den ein Team warten muss und zukünftige Ingenieure schnell und genau verstehen müssen, bin ich überzeugt, dass Standardisierung helfen wird, und ich leite das Team – nicht Sie, nicht Bob, nicht Alice, also muss ich machen diese Art von Anrufen, wenn ich das Bedürfnis verspüre - und das tue ich."

„Wenn Sie in Zukunft solche Projekte leiten, können Sie den Anruf tätigen, den Sie möchten, und erwarten, dass andere Ihren Anweisungen folgen. Aber ich hoffe, wenn Sie das tun – und Sie sind gut, also werden Sie es wahrscheinlich tun [ein Kompliment schadet nie, wenn es ist wahr, wenn nicht weggelassen] - dass Sie es sich noch einmal überlegen und die Vorteile sehen werden, die es bringt, auch wenn es eine Disziplin auferlegt, in der Sie im Moment keinen Sinn sehen.

„Ich glaube, es wird bei der täglichen Arbeit ein wenig Zeit sparen, wenn der Code neu erstellt wird, ich glaube, es wird Fehler reduzieren, und ich glaube, es ist professionell. Ich möchte, dass Sie das respektieren, auch wenn Sie damit nicht einverstanden sind Es."

Denken Sie daran, dass der leitende Entwickler wahrscheinlich besser als der Manager weiß, wie man erfolgreich Code entwickelt.

Whitespace ist eigentlich Teil der pythonSyntax. Die Lesbarkeit ist bereits in der Sprache gestaltet. Tatsächlich hat Python eigene Empfehlungen zum Formatieren Ihres Codes. Best Practices, Namenskonventionen usw. es heißt PEP (genauer gesagt PEP8). Beginnen Sie dort! PEP zu kennen, ist etwas, das sie ihrem Lebenslauf hinzufügen können!

Wie würden Sie mit einer solchen Situation umgehen?

Ich denke, die vier anderen Entwickler stehen mit diesem Argument auf der richtigen Seite und Sie könnten hier falsch liegen. Nehmen Sie ehrlich das Feedback Ihrer Mitarbeiter an und beherzigen Sie es. Versetzen Sie sich in ihre Lage. Wenn der Gehaltsscheck auf Leistung basiert und dieses Tool diese reduziert, nehmen Sie ihnen im Grunde genommen Geld ab .

Ich denke, ein guter nächster Schritt ist die Entscheidung, ob das Tool weiter verwendet werden soll oder nicht. Wenn Sie es für vorteilhaft halten, erklären Sie warum . Zum Beispiel, wenn der Endbenutzer/Kunde Ihnen bessere Bewertungen oder zukünftige Projekte gibt, weil der Code schön ist – sagen Sie das Ihren Mitarbeitern! Das bedeutet mehr Geld in der Tasche!

Denken Sie daran, dass Ihre KPIs für die Qualitätssicherung möglicherweise nicht mit den Stellenbeschreibungen Ihrer Teammitglieder übereinstimmen. Sorgen Sie dafür, dass sich Ihr Team für seine Projekte einsetzt. Machen Sie es zu etwas, auf das sie stolz sind. Wenn ein starkes Gefühl der Eigenverantwortung eine Arbeitsplatznorm ist, ist Qualitätssicherung eine Selbstverständlichkeit.

Nur ein Entwickler im Team widerspricht einer einheitlichen Formatierung, nicht vier. Das erwähnte Tool OP, schwarz, erzwingt PEP8 . Es ist nicht realistisch zu behaupten, dass eine konsistente Codeformatierung die Leistung von irgendjemandem verringert. Ganz im Gegenteil: Der Wert konsistenter Codierungsgewohnheiten ( einschließlich Formatierung) liegt in der Wartungsfreundlichkeit. Die Arbeitsleistung eines Programmierers hängt nicht davon ab, wie viele if-Anweisungen er in einer bestimmten Stunde eingeben kann.
@EdPlunkett Es ist lustig, dass Sie sagen "es erzwingt PEP8", weil ein Abschnitt von PEP8 besagt, dass es nicht erzwungen werden sollte. Daher ist das Erzwingen von PEP8 nicht wirklich konform zu PEP8.
@immibis Du bist ein Geschenk, mein Freund. Ein absolutes Geschenk. Ich wusste nie, dass die souveräne Staatsbürgerschaft nach Python portiert wurde.
@EdPlunkett Ich nominiere dies für den unsinnigsten Kommentar des Monats.
Ganz oben in PEP8: A Foolish Consistency steht der Hobgoblin of Little Minds !

Zwei weitere Punkte könnten eine Überlegung wert sein.

  1. Sie fragen nach einer Schwarz/Weiß-Antwort für ein Graustufenproblem. Ihre Code-Formatierungsregeln könnten vernünftig sein, könnten locker sein, könnten pingelig sein. Ich habe alle möglichen Regeln gesehen. Überprüfen Sie also zunächst, ob die von Ihnen geforderten Codeformatregeln tatsächlich sinnvoll sind oder nicht.
  2. Wurden die Codeformatierung und alle Codestandardregeln nur von oben auferlegt oder von den Entwicklern im Team vereinbart – diejenigen, die den Code tatsächlich schreiben und die den Code von anderen lesen / verwenden? Es könnte eine gute Praxis sein, einen Satz von Standardregeln für die Codierung durch ein Komitee zu beschließen – nur einmal, und dann werden diese Regeln durchgesetzt. Wenn die meisten Entwickler ihnen zustimmen, dann haben Sie eine hohe Chance, dass diese Regeln vernünftig sind, und wenn sich jemand beschwert, ist er wahrscheinlich das Problem. Wenn die Regeln einfach per Dekret einer Person auferlegt wurden ... nun, dann könnten Sie dort ein Problem haben.
  3. Eine Alternative besteht darin, ein Code-Inspektions-/Formatierungstool zu finden, das mehr oder weniger dem Industriestandard für die von Ihnen verwendete Sprache entspricht. Für C# verwende ich beispielsweise Resharper. Dann ist die Entscheidung unvoreingenommen und die Formatierung kann mehr oder weniger automatisch im Editor erfolgen, während der Code geschrieben wird. Wenn Resharper glücklich ist, bin ich glücklich. Finden Sie so etwas für Python.

Meine persönliche Faustregel, wenn ich ein Team leite, ist, nur dann auf strenge Regeln zu bestehen, wenn der Code von jemandem wirklich hässlich aussieht ... und wenn das passiert, könnten wir uns mit einem tieferen Problem als nur der Codeformatierung befassen. Ein Problem, das von der Personalabteilung und der Einstellung der falschen Person ausgeht. Andernfalls, wenn der Code mehr oder weniger klar und organisiert aussieht und seine Architektur / sein Design gut ist, verursacht die Kleinigkeit bei der Formatierung oft mehr Ärger, als es wert ist.

Konsistenz ist ein schwaches Argument. Für eine Person, die mit einer bestimmten Formatierungsregel nicht einverstanden ist, könnte es sich anfühlen, als gäbe es ein Problem mit Mikromanagement oder mit einem machthungrigen Architekten. Formatierung spielt fast nie eine Rolle - "es ist wie bei Farben, manche Leute mögen es rot, andere blau".

Der wirkliche Vorteil automatisierter Formatierungsregeln besteht darin, dass Programmierer keine Zeit damit verschwenden, Dinge zu diskutieren, die keine Rolle spielen. Zu viel Zeit wird in Code-Reviews zu Kommentaren über Einrückungen verbracht. Viel mehr Gehirnleistung sollte auf echte Probleme mit dem Code konzentriert werden.

Stellen Sie dem Entwickler den Begriff Bikeshedding vor . Machen Sie deutlich, dass Sie seine Kommentare als einen großartigen Beitrag zur Gestaltung von Fahrradunterständen ansehen. Er verschwendet die Zeit anderer. Er ist ein schlechter Teamplayer. Es wird während der Auswertung gegen ihn verwendet.

Zusätzlich zu den anderen Antworten, die The Talk bereits ziemlich gut behandelt haben - eine Methode, um Formatierungen in Ihren Prozess einzuführen, ob es Bob gefällt oder nicht:

Führen Sie Code-Reviews nach dem Vier-Augen-Prinzip bei jeder Merge-Anfrage durch. Sie mastersollten nur mit akzeptierter Zusammenführungsanforderung geändert werden, auf keine andere Weise. Alle Merge Requests müssen einer Qualitätssicherung unterzogen werden, dh ein anderes Teammitglied muss sich den Code ansehen. Erzwingen Sie die Formatierung und lassen Sie Bobs MRs aufgrund falscher Codeformatierung zurückweisen.

Wenn Bob sich weigert, dem nachzukommen, bleiben seine Merge-Anfragen in der Schwebe. Auf die Frage „Warum ist Feature XY nicht fertig, obwohl die Deadline längst verstrichen ist?“, antwortet Bob vielleicht: „Das ist schon eine Weile so, wurde aber von Kollege Y abgelehnt“. Sie können argumentieren, dass es dann nicht getan wird. Dafür ist Qualitätskontrolle da. Kollegen müssen solche Anfragen ablehnen und Bob neu zuweisen, es ist dann Bobs Aufgabe, sich darum zu kümmern.

Es gibt verschiedene Grade von Aggression, wenn Sie sich auf diese Weise verhalten. Wenn Sie also möchten, dass der Ton so freundlich wie möglich bleibt, achten Sie darauf, wie Sie dies umsetzen. Trotzdem - Sie sollten Code-Reviews trotzdem machen.

In einer persönlichen Anmerkung - Bobs angebliche Aussagen über die Nützlichkeit der Formatierung lassen mich glauben, dass sie möglicherweise nicht für eine Hauptrolle geeignet sind oder einfach keine spezifische Ausbildung in bestimmten Bereichen haben. Vielleicht kennen sie die Codebasis in- und auswendig, aber aufgrund fehlender Best Practices haben sie dazu beigetragen, sie in ein riesiges Durcheinander zu verwandeln, und nur sie kennen einen Weg durch das Chaos. So etwas ist gefährlich, da Sie sehr abhängig von einer einzelnen Person werden können, wenn Ihre Codebasis immer weniger wartbar wird.

Ich denke, dass es in diesem Fall vielleicht möglich wäre, einen Git-Hook hinzuzufügen, der das Codeformat in das vom Team beim Commit gewünschte ändert, und einen anderen (nur von ihnen verwendet), der das Codeformat in das von gewünschte ändert das Teammitglied auf Update.

Wenn das Teammitglied so stark davon überzeugt ist, kann es auch eine gute Gelegenheit sein, mehr über den Code-Formatierer und die Git-Werkzeuge zu erfahren, alles Wissen, das später nützlich sein kann.

Ein großes Nein. Es ist anfällig für Inkonsistenzen und es gibt keine Möglichkeit, dass sich das gesamte Team an das grundlose Jammern eines Einzelnen anpassen muss.
Irgendwie gefällt mir Ihre Idee, aber es gibt einfach zu viele Dinge, die das Tool nicht beheben kann (z. B. alles in Kommentaren wie Beispielcode in Autodoc-Anmerkungen, jede neuere Syntax, für die es nicht gepatcht wurde usw.). Es lohnt sich nicht, den Code des Angreifers ständig doppelt zu überprüfen und bei jedem Pull-Request mehrere Fehler bei der Codeüberprüfung zu durchlaufen.
Ich weiß nicht, wie relevant es für Python ist, aber wir hatten früher ein Tool (mehr auf das Vergleichen / Zusammenführen beschränkt), das die Sprachsyntax kannte und syntaktisch bewusste Unterschiede machte.
Das klingt lächerlich fehleranfällig, und der Typ des Kollegen kommt mir vor wie jemand, der sich jedem Codestil oder jeder Autokorrektur widersetzen würde (dh er ist nicht konsequent in seinem eigenen Stil). Dies ist nicht machbar.

Hier gibt es viele Antworten, die sich auf gute technische Argumente konzentrieren. Zusammenfassend: Das Team hat eine fundierte Entscheidung getroffen, wie es weitergehen soll, und eine Person lehnt die Teamentscheidung und die Anweisungen des Managers ab.

Das Gespräch, das ich führen würde, geht eher in die Richtung: Haben Sie meine Anweisungen und die Teamentscheidung gerade als "Bullshit" bezeichnet? Haben Sie sich wirklich darüber beschwert, dass die Bezahlung für die Arbeit "Ihre Freiheit einschränkt"? Ich empfehle dringend, dass Sie Ihren Code jetzt gut formatiert einchecken, und ich werde ein Treffen mit der Personalabteilung vereinbaren, um den Respekt gegenüber Ihrem Arbeitgeber, Ihrem Vorgesetzten und Ihrem Team zu besprechen.

Du sagst also, eine Entscheidung ist die richtige Entscheidung, weil sie von oben kommt und Respekt da sein sollte? Ich würde sagen nein, genau so sollten Tech-Unternehmen nicht arbeiten, Programmierer sollten davon überzeugt sein, was sie tun und wie, nicht gezwungen. Das wäre sehr unproduktiv bis gefährlich.
@Mayou36 Nein, was ich sagen will: Team-Tools "b*****t" zu nennen, liegt außerhalb des Bereichs professioneller Kommunikation, insbesondere wenn Sie keine handfesten Argumente haben. Und zu sagen, dass Richtlinien bei der Arbeit "Ihre Freiheit einschränken", ist ein seltsames Verständnis eines Arbeitsvertrags. Vor allem für etwas, das eigentlich ein Teamthema ist.
@ Mayou36 vielleicht postest du den Kommentar zur falschen Antwort. Diese Antwort befasst sich mit der politischen/zwischenmenschlichen Seite des Problems und trifft kein Urteil über das technische Problem: Sie wird als „solide“ angesehen, weil sie von Management und Team nur eins vereinbart wurde.
Nein, Mayou hat Recht. Wenn Sie einen Programmierer (oder irgendjemanden anderen) einstellen, erhalten Sie mit jedem Mitarbeiter ein kostenloses Gehirn. Wenn Sie sie schikanieren – und diese Antwort wäre eine schikanierende, auch wenn einige sie als gültig/legitim ansehen –, schaden Sie der Moral und der Produktivität. Andere werden wissen, dass Sie so reagieren, und zwischen Ihnen und dem Team wird sich eine Kluft bilden, und Dinge, die Sie hören müssen, werden Ihnen nicht gesagt, zu Ihrem eigenen Schaden und dem des Teams. Schlechte Manager zwingen früh. Gute Führungskräfte probieren kooperative Ansätze aus und sparen sich harte Linien für den tatsächlichen Bedarf auf, wegen Dringlichkeit oder wegen anderer...
... Ansätze sind gescheitert. Aber trotz der Gespräche im OP sehe ich in der Frage nichts, was darauf hindeutet, dass dieser Punkt erreicht wurde, da keine Beschreibung eines Versuchs beschrieben wird, die Situation tatsächlich und angemessen zu bewältigen. Der OP fragt, wie man jetzt damit umgeht. Eine Mobbing-Reaktion ist also übertrieben, und ich würde mit jedem Manager sprechen, von dem ich gesehen habe, dass er seinem Team schadet, wenn ich das ohne wirklich guten Grund sehen würde – der noch nicht existiert: und diese Situation als einen Weg zu nutzen ihre Personalführungsfähigkeiten verbessern - und prüfen, ob wir ein kulturelles Problem haben.
@Stilez: Einen Mitarbeiter darüber zu informieren, dass Ungehorsam und Ablehnung der Teamarbeit irgendwann berufliche Konsequenzen haben kann, ist kein Mobbing. "B******t" zu nennen, was Ihre Kollegen sagen, ist.
"Irgendwann"... Und so. Es ist eher die Art und Weise als die Informationen, die mich dazu bringen, es als Mobbing-Reaktion zu sehen. Die gleichen Informationen können auf viele Arten gegeben werden, und das Problem kann auch auf viele Arten behandelt werden. Die Eskalation zu einer impliziten Bedrohung ist für das OP wie beschrieben einfach nicht erforderlich oder hilfreich, und die Antwort scheint kein angemessenes Urteil darüber zu sein, wo dieser Punkt liegt, und zeigt kein Verständnis für Management – ​​Soft Skills und Teambuilding. Sie können einen Streit mit Gewalt gewinnen, aber trotzdem Ihr Team, Ihren guten Willen, Ihre Zusammenarbeit und (langfristig) den Krieg verlieren. Diese Antwort geht in diese Richtung.
Bezüglich „das Team hat eine vernünftige Entscheidung getroffen, wie es weitergehen soll“, habe ich den Eindruck, dass nicht das Team als Ganzes diese Entscheidung getroffen hat, sondern der Manager, der die Entscheidung getroffen hat und unseren Rat möchte, wie er/sie es tun kann sie ihrem Team auferlegen. Daher das Problem.
@Paolo, das ist mein Punkt, wenn sich das Team und das Management darauf geeinigt haben, würde ich dringend davon abraten, "Ich bin Ihr Vorgesetzter" als Argument zu verwenden, um ihn zum Folgen zu bringen. Es ist wie eine „ultima ratio“ und sollte zur Schadensverhütung da sein, nicht als Geschäftsidee, schon gar nicht für Entwickler. Holen Sie ihn auf Ihre Seite, befehlen Sie ihm nichts.
@Stilez: nein, Mobbing wäre folgendes: Vor dem Team sagen "Geh, pack deine Sachen und kündige. Wir haben keinen Platz für spezielle Ponys".
Nein. Vielleicht möchten Sie denken, dass es nicht so ist. Wenn Sie so etwas routinemäßig tun, werden Ihre Mitarbeiter eine andere Geschichte erzählen, wenn sie von der Arbeit nach Hause gehen. Und das ist die Geschichte, die zählt, Sie können keine GWB-Neudefinition machen, dass Waterboarding nicht wirklich Folter ist, oder diese Art von Drohungen aussprechen (was sie sind), da Ihre grundlegende Reaktion nicht wirklich Mobbing ist. Sie werden es so sehen und Ihr Team wird der Verlierer sein. Machen Sie kein Mobbing-Verhalten, auch wenn Sie das nicht für das richtige Wort dafür halten.
Die Frage ist, wer ist in dieser Situation der Tyrann? Der leitende Entwickler, dessen Autorität in Bezug auf das Projekt gerade untergraben wurde und der (etwas) verständlicherweise negativ auf die Nachricht reagiert hat, oder der Manager, der jetzt nach Wegen sucht, seinen Entwickler dazu zu bringen, sich seinen Äußerungen anzuschließen? Nur Zugang zu einer Seite der Geschichte zu haben, macht es schwierig, dies zu nennen. Soweit wir wissen, wurden die vom OP zitierten Kommentare möglicherweise vom leitenden Entwickler vertraulich, privat, in der Bar nach der Arbeit gemacht. Der Kontext ist alles, und wir wissen es einfach nicht.
Markus: Oder gar nicht. Weil die meisten Zitate wie leichte Änderungen an sehr vernünftigen Aussagen aussehen.
Teammitglied ist vehement gegen Codeformatierung
AntwortenHierDatenschutz-Bestimmungen1y, 0v