Uneinigkeit mit Projektleitung zu Kodierungsstandards [geschlossen]

Deshalb arbeite ich zusammen mit meinem Projektleiter seit einem Jahr an einem neuen Projekt.

Anfänglich hatten wir unsere eigenen Unterprojekte, die sich in separaten Git-Repos befanden. Ich hatte wenig Interaktion mit seinem Code, so dass der Codegeruch mich nicht störte. Etwa 6 Monate später begann ich, seinen Code zu pflegen und Features hinzuzufügen, da ich eine größere Rolle in dem Projekt einnahm.

Jetzt, da ich der Hauptentwickler für beide Teilprojekte bin (Team im Begriff zu wachsen; er ist immer noch über mir), stören mich diese Dinge und ich wollte mich darum kümmern, wurde aber abgelehnt:

1. Keine geschweiften Klammern, großgeschriebene Funktionen, gemischte Anführungszeichen (doppelte und einfache mit versteckter Logik), keine Verwendung von ===, riesigen Klassen mit riesigen Funktionen. Fazit, könnte besser sein.
2. Verlassen Sie sich auf die Option von PHP, um Hinweise / Warnungen auszuschalten. Code ist voll von ungeprüften Verwendungen von Variablen und Array-Schlüsseln. Variablen werden innerhalb von ifs definiert.

Argumente zu den obigen 2 Punkten:

1. Sie möchten den Menschen keinen Codierungsstil aufzwingen.
2. Wird als Sprachfunktion angesehen, die sich für kürzeren / effizienteren Code eignet.

Ich bin der Meinung, dass einige Regeln eingehalten werden müssen und der Code defensiv sein sollte. Ich habe angeboten, die Standardeinstellungen von PHPStorm für die Formatierung zu verwenden, geschweifte Klammern und eine von der Community akzeptierte Namenskonvention zu verwenden.

Ich möchte beide Projekte so ausrichten, dass sie dieselben Richtlinien verwenden, da sie untrennbar miteinander verbunden sind.

Bin ich falsch Lege ich meine persönlichen Vorlieben fest?

Wenn Sie überzeugend begründen können, warum Ihre besser ist (und welche Hauptprobleme bei der Verwendung seiner auftreten können), dann legen Sie meiner Meinung nach keine persönlichen Präferenzen auf, sondern versuchen, ein Projekt für den Erfolg vorzubereiten.

Wenn er ein stärkeres Argument dafür abgeben kann, warum er besser ist und welche Art von Problemen es verhindern wird, dass Sie es nicht können, dann hat er Sie in den Schatten gestellt.

Ein anständiges oberes Management sollte in der Lage sein, den Vorzug darin zu sehen, aber das sind die Punkte, die es interessieren (und sollten): nicht, ob es für Entwickler einfacher ist oder ob "nicht jeder gezwungen werden soll, wie ein Roboter zu arbeiten" (was) ist ein lächerlicher Punkt, aber verwenden Sie ihn nicht als Schmerzpunkt für das obere Management. Sie (sollten) sich um die laufende Stabilität des Projekts kümmern.

Nach meinem Kommentar oben:

Wenn er der Projektleiter ist, scheint das zu bedeuten, dass es im Grunde seine Berufung ist.

Das war mein gedanke Wenn Sie den Standard ändern möchten, er sich aber nicht davon abhebt, a) finden Sie heraus, wie Sie über ihn hinwegkommen können, b) gehen Sie woanders hin, um zu arbeiten, oder c) versuchen Sie, welche kleinen Dinge Sie tun können, ohne ihn zu irritieren zu viel.

Sich über ihn zu erheben, wird nur funktionieren, wenn Sie mit Nachdruck begründen, warum es bessere Standards geben sollte.

Grundsätzlich:

• Sie tun nicht wie seine Codierung Stil. Das ist dein Recht.
• Er findet es OK, wie es ist, und findet, dass es Zeitverschwendung ist, Tage / Wochen / mehr damit zu verbringen, den Stil anzupassen . Das ist sein Recht.

Versetze dich in seine Schuhe. Was sind die Vorteile Ihres Unternehmens, abgesehen davon, dass es dem Unternehmen viel Geld kostet (Ihr Gehalt)? Ist er immer so pingelig? Sieht er nicht, dass es jetzt wichtigere Dinge zu tun gibt?

Grundsätzlich müssen Sie einen Kompromiss finden, mit dem Sie leben können, sonst wird Ihre Beziehung sauer. Es hängt auch sehr davon ab, wie Sie mit ihm kommunizieren. Legen Sie Ihr Ego beiseite und versuchen Sie, hilfreich zu sein. Schließlich fragen Sie ihn nach Dingen, die Sie möchten, und nicht nach etwas, an dem er interessiert ist. Mit anderen Worten, Sie bitten ihn um einen Gefallen .

Es hängt auch oft davon ab, wie Sie fragen. Beispiele:

Was Sie wollen:

den Code schöner machen

Was nicht zu sagen:

Ihr Code ist scheiße wie er ist

Was zu sagen:

Ich würde es wirklich begrüßen, wenn ich beide Projekte konsistent machen könnte, nur die Grundlagen, und es wird nur einen Tag dauern.

Was Sie wollen:

keine ungeprüften Warnungen mehr

Was nicht zu sagen:

Ihr Code ist scheiße wie er ist

Was zu sagen:

Ich kenne einen schnellen Weg, um diese und jene Warnung loszuwerden. Wenn wir sie dann wieder aktivieren, können wir schneller erkennen, ob in Zukunft etwas kaputt geht.

Und zuletzt:

Ich weiß, dass es keine Priorität ist. Also kann ich es gerne tun, wenn erst einmal wichtige Dinge vom Tisch sind.

Oder wenn das nicht klappt oder Sie eine schlechte Beziehung zu ihm haben, ziehen Sie in Betracht zu gehen. Wenn Sie die Dinge jetzt nicht regeln können, wird es in Zukunft wahrscheinlich nicht besser ... und legen Sie Ihr Ego beiseite.

Randnotiz

Ich denke, es ist üblicher, dass ältere Menschen nachsichtiger sind. Sie wissen , dass der Code wird im Papierkorb in einem Jahrzehnt oder zwei ohnehin (weil die Technologie ändert, APIs auch Teams, Geschäftspartner, Anforderungen, globale Entscheidungen, was auch immer ...). Sie haben weniger Ego und konzentrieren sich darauf, dass es funktioniert, anstatt perfekt zu sein. Obwohl ich selbst zur Perfektion neige, kann ich ihnen keine Vorwürfe machen.

Dies wird wahrscheinlich umstritten sein, aber ...

Wir haben darüber gesprochen und uns darauf geeinigt, dies abzulehnen und es an das höhere Management weiterzuleiten

Noch nie. Je. Tun. Dies. JE. Jedes Mal, wenn Sie dies tun, setzen Sie uns alle ein Jahrzehnt zurück. So läuft das ab:

• Senior Manager 1: "Wir wurden gebeten, uns mit diesem Problem zu befassen, bla, bla, etwas über Kodierungsstandards und Zeitverschwendung."

• Senior Manager 2: "Und sie bitten uns , ihre Nerd-Kriege zu lösen, weil?"

• Senior Manager 3: "Weil es sich um weinerliche Babys handelt, die nicht kommunizieren können und sich nicht darum kümmern / verstehen, was der geschäftliche Wert ist? *"

• Senior Manager 2: "Das muss es sein. Wer ist golfen?"

Dann kommen Sie und Ihr Chef zur Leistungsbeurteilung:

"[Senior Manager zu Ihrem Chef]: Es tut mir leid, aber es gibt einige Bedenken, dass Sie Ihre direkten Berichte nicht verwalten können und Sie möglicherweise nicht die besten Praktiken befolgen (obwohl ich keine Ahnung habe, was Sie tun, außer etwas Hokuspokus einzugeben das macht die Software funktionsfähig) "

"[Senior Manager zu Ihnen]: Es tut mir leid, aber es gibt einige Bedenken, dass Sie sich nicht gut mit Ihren Kollegen identifizieren und Probleme haben, den Anweisungen Ihres direkten Vorgesetzten zu folgen."

Und deshalb sind wir im Vergleich zu dem Wert, den wir schaffen, meistens unterbezahlt. **

Sie müssen entweder A) darüber hinwegkommen oder B) zu einem Geschäft übergehen, dessen Standards etwas näher an Ihren Wünschen liegen. FWIW, ich würde B machen (und hoffentlich zu einer Sprache übergehen, die solche Gräueltaten nicht zulässt). Aber eskalieren Sie niemals einen technischen Streit um die Anzüge, es sei denn, es handelt sich um etwas Illegales oder potenziell Katastrophales (klaffendes Sicherheitsloch). Nur nervig macht es nicht ***.

* Zum Wohle der Leute, die dies lesen und missverstehen, sage ich nicht, dass das OP und sein Chef so sind (mir ist klar, dass die Codequalität / Lesbarkeit einen direkten Einfluss auf das Geschäftsergebnis hat), sage ich dass sie vom nicht-technischen Management so wahrgenommen werden.

** Für Leute, die mein Porträt des oberen Managements für ahnungslos halten, ist es unrealistisch, zu verstehen, dass es den Managern (im Idealfall) wichtig ist, Menschen so zu managen , wie es uns um den Umgang mit Code geht. Sie mögen in technischen Fragen ahnungslos sein, aber sie kennen die Leute, und das ist umso mehr der Grund, warum sie einen Streit darüber haben, dass A) sie wahrscheinlich nicht in der Lage sind, eine Lösung zu finden, und B) Sie beide es wohl ohne Hilfe hätten tun sollen macht dich schlecht aussehen.

*** Ja, mir ist klar, dass sich technische Schulden so weit häufen können, dass das Geschäft sinkt. Ich glaube einfach nicht, dass geschweifte Zahnspangen Sie retten werden (allerdings lasse ich die Zahnspangen nie aus und bevorzuge andere auch nicht).

IMHO, Sie haben es mit einem Entwickler zu tun, der gerade arbeitet und sich nicht um den nächsten kümmert. Seine Argumente sind einfach wertlos.

Alles, was Sie über seinen Code sagen, ist nur rohe Faulheit von seiner Seite. Projekte, die dem gleichen Kodierungsstandard folgen, sind streng. Sie sind keine Roboter; Sie sind Ingenieure; du sollst streng sein.

Sie könnten an einigen Beispielen darauf hinweisen, dass es Ihnen schwer fällt, seinem Code zu folgen, und das ist ein enormer Produktivitätsverlust für Sie, aber ich habe keine wirkliche Idee, wie ich das zu ihm bringen kann.

Aber ich werde dir wahrscheinlich antworten, dass etwas der Ton ist:

Es funktioniert, kein Grund, sich zu ändern

Mein Rat: Wenn er wirklich stumpf ist und nichts vorhaben will, lass es los. Warten Sie, bis in seinem Projekt Fehler / Bugs / Evolution aufgetreten sind. Wenn es darum geht, korrigieren Sie einfach den Teil des Codes, der auf die richtige Weise geändert / hinzugefügt wurde, und schreiben Sie ihn neu. Geh nicht zu ihm, um etwas darüber zu sagen. Er wird Ihnen seinen Codierungsstil nicht aufzwingen, da Sie sowieso kein Roboter sind ...

Wenn Sie an einem Projekt arbeiten, müssen Sie Prioritäten setzen.

Priorität 1 ist, mit Ihren Mitarbeitern auszukommen. Auf Priorität 1 folgt eine große Lücke. Dann kommen Prioritäten für Dinge wie Code, der funktioniert, testbar, getestet, dokumentiert, wartbar usw. Dann kommt eine weitere große Lücke und dann kommen Codierungsstandards.

Die Anpassung des vorhandenen Codes an neue Codierungsstandards ist auf der Prioritätenliste sehr niedrig.

PS. "Mikrooptimierung" vs "superschnelle Computer": Völlig falsches Argument. Das Argument gegen die Mikrooptimierung ist nicht, dass Computer schnell sind. Das Argument ist, dass Zeitverschwendung durch Mikrooptimierungen bedeutet, dass Sie keine Zeit für echte Einsparungen haben.

PS. Wenn Sie nur einen Tag brauchen, um Änderungen vorzunehmen, die den Code für Sie besser erscheinen lassen, Ihren Kollegen jedoch verärgern und Sie zu einem Feind machen, haben Sie einen Tag mit etwas verschwendet, das nur kontraproduktiv ist.

PHP ist nicht die Elite-Gruppe in unserem Beruf. Eigentlich kritisieren Sie sein wohl hart erkämpftes Softwaresystem. Ihr beruflicher Standard ist höher als sein.

Dann , wenn Sie haben keinen Spielraum , den Code unter Ihrer Verantwortung zu verbessern, zuletzt nur eine Lösung: Bewegung auf .

Ich kenne den aktuellen PHP-Markt bei Ihnen nicht, aber Sie könnten zunächst etwas diversifizieren. Lernen Sie auch eine Hype-Sprache oder eine Nische wie C #.

Sie werden vielleicht keinen so schönen Job bekommen, aber Sie werden professionell weiter kommen. Haben Sie also Geduld und lernen Sie selbst. Sicheres Geld. Bitten Sie dann um etwas Spielraum in Ihren Projekten oder nehmen Sie ein Stellenangebot an.

Es fällt mir schwer zu glauben, dass # 1 sein eigentlicher Grund ist, die Kodierungsstandards nicht ändern zu wollen. Wenn Sie Eigentümer der Codebasis sind, sollten Sie in der Lage sein, die Codierungsstandards durchzusetzen, denen Sie (und die anderen Entwickler) zustimmen. Wenn Sie mit den anderen Entwicklern einen Konsens erzielen (vorausgesetzt, der Lead führt keine Entwicklungsarbeit mehr aus), gibt es keinen Grund für ihn, sich wirklich darum zu kümmern, außer diesem:

Ist das Korrigieren des Stils der Codebasis derzeit die beste Verwendung Ihrer Zeit?

Ich bin sicher, Sie haben Ergebnisse. Wie viel Zeit wird es kosten, den Stil überall in der anderen Codebasis zu verbessern? Was ist, wenn Sie Fehler einführen, indem Sie den Stil falsch korrigieren? Von Onkel Bob:

Natürlich kann schlechter Code bereinigt werden. Aber es ist sehr teuer. Während der Code rotiert, unterstellen sich die Module gegenseitig und erzeugen viele versteckte und verwickelte Abhängigkeiten. Alte Abhängigkeiten zu finden und zu lösen ist eine lange und mühsame Aufgabe.

Das Verbessern des Code-Stils ist als eigenständiges Sprint-Element so gut wie nie sinnvoll . Die Art und Weise, wie ich diese Art von Verbesserungen vornehme, nenne ich "Good Neighbor Policy": Gehen Sie nicht darum herum, den Stil und die logische Struktur zu reparieren, die Sie finden können, weil Sie wahrscheinlich so viel Zeit investieren, wie Sie wollen und immer noch wollen nicht getan werden. Stattdessen: Wenn Sie Änderungen an einem Teil des Codes vornehmen, korrigieren Sie den Stil, während Sie dort sind, und lassen Sie ihn besser, als Sie ihn gefunden haben. Wenn Sie Schwierigkeiten haben, eine Funktion zu implementieren, weil der Code schlecht entworfen wurde, korrigieren Sie den Stil, um sich selbst zu entsperren, anstatt sich mit dem Kopf dagegen zu schlagen.

Auf diese Weise wird jede Änderung:

1. Hat eine Geschäftsmotivation zusätzlich zur technischen Perfektionismusmotivation
2. Wird nicht als große Investition angesehen (weil es nicht ist!)
3. Stellt gute stilistische Gewohnheiten her, gerade weil Sie und Ihr Team dies im Laufe der Zeit tun
4. Stellt kein großes Risiko für die Codebasis dar, da Sie nicht zu viel auf einmal ändern

In ein paar Monaten werden Sie nachsehen und feststellen, dass das "schreckliche Paket" nicht mehr so ​​schlecht ist und Ihr Chef sieht, dass sein Team glücklicher ist. Aber weil es keine direkte Konfrontation war, wird es bereits geschehen, und er wird nichts zu beanstanden haben, weil Sie (seiner Meinung nach) keine Zeit verschwendet haben, indem Sie der To-Do-Liste ein großes Refactoring-Projekt hinzugefügt haben. Er wird dir wahrscheinlich nie sagen, dass du recht hattest, aber das ist sowieso nicht das Ziel (oder?).

Stellen Sie diese Fragen zu Ihrem Lead.

• Sind sie es gewohnt, alleine oder in einem sehr kleinen Team zu arbeiten?
• Haben sie meistens in diesem einen Laden codiert?
• Sind sie es gewohnt, Entscheidungen zu treffen?
• Sind sie es gewohnt, "es einfach zu erledigen"?
• Haben sie den größten Teil des Codes geschrieben?

Wenn die Antworten "Ja" lauten, male ich ein Bild von einem bestimmten Programmierertyp. Wenn es mit dem übereinstimmt, was Sie erlebt haben, hilft es vielleicht, in den Kopf zu geraten. Wenn nicht, ignorieren Sie diese Antwort .

Dies ist jemand, der vom ersten Tag an dabei war, Jahre im selben Job an derselben Codebasis gearbeitet hat, es gewohnt ist, sich zu behaupten, und nicht viel Erfahrung mit anderen Methoden hat.

Sie berücksichtigen beim Schreiben von Code keine anderen Personen, da für sie alles einen Sinn ergibt. Natürlich, sie haben es geschrieben oder sie haben Jahre damit verbracht, es zu verstehen.

Sie betrachten den Codierungsstil als eine persönliche Präferenz, nicht als ein Werkzeug zur Reduzierung von Wartung und Fehlern. Wenn sie über den Codierungsstil streiten, werden sie Schwierigkeiten haben, Ihre Argumente zu hören, weil sie sich wahrscheinlich noch nie Gedanken darüber gemacht haben, warum sie die Dinge auf ihre Weise tun. Was sie hören werden, ist "Ich möchte es auf meine Art tun" oder "Ich möchte es auf die neue, schicke, trendige Art tun".

Sie sind auf ihre Art und Weise festgelegt. Weil sie es seit so langer Zeit auf die gleiche Weise machen, sind alle Werkzeuge und Editoren und das Gehirn genau auf ihren Stil mikrokonfiguriert. Jede Abweichung von diesem Stil widerspricht dieser sorgfältig arrangierten, aber sehr spröden Arbeitsweise. Bei Änderungsversuchen wird es zu Beschwerden über den Editor, die Tools, die Art und Weise, in der sie arbeiten, oder über die Schwierigkeit des Lesens kommen. Sie lehnen Veränderungen ab, weil sie sich in den Status Quo vertieft haben, den sie nicht ändern können.

Dies ist jemand, der Software-Engineering und Software-Architektur noch nie richtig gelernt hat. Sie schlagen einfach irgendwie zusammen, was auch immer funktioniert.

Sie haben ein Menschenproblem, kein technologisches.

Sie müssen Ihre Führung neu trainieren, oder Sie müssen aufhören.

Das Management ist der letzte Ausweg . Sowohl aus den Gründen, auf die @JaredSmith hingewiesen hat, als auch, weil Sie verlieren werden. Dieser Typ hat Jahre damit verbracht, Geld für sie zu verdienen. Er schrieb ihre Firma. Er ist in zahlreichen Bränden gelöscht. Für Sie ist er ein Cowboy-Koch, der Spaghetti macht. Für sie ist er ein Held, der die Firma aufgebaut und gerettet hat.

Um wieder zu trainieren, müssen Sie ...

• Gewinnen Sie sein Vertrauen.
• Finde heraus, wie er denkt.
• Gehen Sie auf seine Ängste vor Veränderungen ein.
• Erleichtern Sie das Wechseln.
• Zeigen Sie, wie das für ihn besser ist .

Nimm seinen Stil ernst und gehe in seinen Kopf. Fragen Sie ihn danach. Warum macht er die Dinge so wie er? Was sieht er, wenn er es liest? Wie interagiert es mit seinen Werkzeugen? Wie bewegt er sich durch den Code? Wenn Sie all diese Dinge kennen, können Sie seine Einwände verstehen und ansprechen.

Finden Sie die objektive Wurzel seiner subjektiven Einwände, machen Sie sie umsetzbar. "Es ist schwer zu lesen" ist subjektiv und gibt Ihnen keine Informationen. Daran kann man nichts ändern. "Ich bin farbenblind und Syntaxhervorhebung funktioniert nicht" ist objektiv, gibt Ihnen Informationen und Sie können etwas dagegen tun. Ich würde ein Buch mit dem Titel Getting To Yes empfehlen, um mehr darüber zu erfahren.

Sobald Sie das eigentliche Problem gefunden haben, können Sie prüfen, ob Sie es beheben oder abmildern können. Dann ist das kein Problem. Sie werden wahrscheinlich immer noch emotionale Probleme mit Veränderungen haben, aber zumindest können sie nicht länger behaupten, dass es sich um ein tatsächliches Problem handelt.

Mach es ein bisschen nach dem anderen. Das ist jemand, der es seit Jahren genauso macht. Er ist es gewohnt, bestimmte Muster im Code zu sehen und sie zum Verstehen zu verwenden. Das plötzliche Ändern all dieser Muster wird verwirrend sein. So frustrierend es auch sein mag, sie mit bewährten Methoden langsam auf den neuesten Stand zu bringen, Sie müssen ihn durch die Übung führen.

Für einen Standard-Community-Stil eintreten. Dies beseitigt das Argument, dass es um persönliche Vorlieben geht, und übt den Druck auf sie aus, zu rechtfertigen, warum ihr unterschiedlicher Stil so viel besser ist. Wenn Sie eine Einstellung planen, wird die Integration von Neueinstellungen erleichtert.

Fürsprecher für automatisierten Codestil. Machen Sie das Befolgen des richtigen Stils zum Knopfdruck. Verwenden Sie ein Tool, das mit einem Standardstil beginnt, mit dem Sie es nach Ihren Wünschen konfigurieren und den Code per Knopfdruck neu formatieren können. Wenn es so einfach wie möglich ist, dem Stil zu folgen, werden viele Argumente dahingehend beseitigt, wie schwierig es sein wird, dem Stil zu folgen. Sie können programmieren, wie sie möchten, und wenn sie fertig sind, drücken sie einen Knopf und es folgt einem Stil, den andere lesen können.

Da diese Person nicht an andere denkt, müssen Sie zeigen, wie diese Änderungen für sie von Nutzen sind. Es kann so einfach sein wie "da dies der Standard ist, müssen Sie diesen Kampf nicht noch einmal mit der nächsten Person, die Sie einstellen, durchmachen". Oder es kann sein, "wenn wir Tests haben, können Sie aggressiver beim Ändern des Codes sein und sich weniger Gedanken über das Ändern von Dingen machen". Oder "Wenn es gute Dokumente gibt, müssen sich die Leute nicht ständig mit Fragen zur Funktionsweise des Codes beschäftigen". Damit dies effektiv ist, müssen Sie wissen, was sie wollen - manche Menschen mögen es, belästigt zu werden, es gibt ihnen das Gefühl, wichtig zu sein.

Es ist ein langer, langer Weg. Sie müssen sich entscheiden, ob Sie die Geduld haben, Ihren Chef zu managen und neu zu schulen. Betrachten Sie sich eher als ihren Lehrer als als ihren frustrierten Untergebenen, und Sie fühlen sich vielleicht besser dabei.

Bin ich falsch

Ich kenne PHP nicht und kann daher kein direktes Urteil fällen, aber ich gehe aus Gründen der Argumentation davon aus, dass Ihr bevorzugter Codierungsstil "besser" ist als der Code, auf den Sie gestoßen sind, da Ihr Code mehr im Einklang steht mit vorhandenen automatisierten Werkzeugen.

Dann sind Sie nicht falsch, Verbesserungen des Codierungsstils vorzuschlagen.

Fazit, nicht Code, mit dem ich arbeiten möchte

Es kann falsch sein, dass Sie sich weigern, mit Code zu arbeiten, der nicht Ihren bevorzugten Standards entspricht, sondern nur in dem Maße, in dem Sie bei der Firma zugestimmt haben, überhaupt mit dem Code zu arbeiten. Letztendlich ist es nicht "falsch", Ihren Job zu kündigen, wenn es Anforderungen an Sie stellt, die nicht Ihren Wünschen entsprechen, da dies Ihr Recht ist und Sie möglicherweise einen besseren Job finden.

Lege ich meine persönlichen Vorlieben fest?

Nein, er ist der Projektleiter und Sie nicht. Es ist sein Ruf, obwohl er in diesem Fall "nach oben delegiert" ist.

Genauso gut hätte er sich entschlossen, Sie als Hauptentwickler der Teilprojekte nach unten zu delegieren und Ihnen freie Hand zu lassen, um die Kodierungsstandards für die Teilprojekte und Kollegen festzulegen, die in Zukunft daran arbeiten. Aber aus welchen Gründen auch immer, er ist der festen Überzeugung, dass man nicht standardisieren sollte. Selbst wenn er sich in Bezug auf den Codierungsstil irrt , können Sie nicht erwarten, eine Autorität zu beanspruchen, die er Ihnen nicht erlaubt hat.

Da er jedoch sagt, dass ich Codierungsstile nicht erzwingen möchte, können Sie zumindest neuen Code in Ihrem bevorzugten Stil schreiben (und haben dies getan). Letztendlich könnte dies zu Gelegenheiten führen, die objektiven Vorteile Ihres Stils zu demonstrieren. Das wäre ein guter Zeitpunkt, um einen zweiten Versuch zu unternehmen.

Sie können auch (glaube ich) vernünftigerweise Leute, die Dateien bearbeiten, bitten, dies in dem Stil zu tun, in dem die Datei bereits geschrieben ist. Auf diese Weise können Sie Standards in Dateien beibehalten, die Sie geschrieben haben. Leider besteht die Kehrseite darin, dass Sie die Dateien, die er geschrieben hat, in einem ähnlichen Stil bearbeiten müssen.

Selbst wenn Sie eine wirklich gute Testsuite haben und daher die relative Sicherheit verbessern können, gibt es immer noch (zugegebenermaßen eher marginale) Gründe, nicht ganze Dateien zu durchstarten und neu zu formatieren. Die Hauptsache ist, dass es ein Albtraum ist, Änderungen, die vor und nach einem großen Strukturwandel vorgenommen wurden, zusammenzuführen, neu zu ordnen oder rückgängig zu machen. Aber es kann durchaus sein, dass es in diesem speziellen Projekt so gut wie nie passiert.

[Mein Vorgesetzter sagt, er mag es nicht, den Leuten Codierungsstile aufzuzwingen, [weil] wir keine Roboter sind.

Haben Sie sich jemals gefragt, warum wir den Quellcode nicht einfach wegwerfen, nachdem wir ihn kompiliert haben und er alle Tests bestanden hat? Quellcode ist für Menschen und es ist nicht nur für Menschen, zu schreiben, sondern auch zu lesen .

Früher oder später wird jemand einen Grund haben, zurück zu gehen und den Code zu lesen. Vielleicht müssen sie es ändern, vielleicht dokumentieren, vielleicht wiederverwenden. Was auch immer. Es wird passieren, und der Code wird viel einfacher zu lesen und zu bearbeiten sein, wenn alles in einem einheitlichen Stil abläuft.

Auch ein schlechter Stil ist besser als gar kein Stil.