Ist es eine gute Idee, allen Entwicklern dasselbe Codeformat aufzuerlegen?

Wir überlegen, ein einziges Standard-Code-Format in unser Projekt aufzunehmen (automatisches Format mit Speicheraktionen in Eclipse). Der Grund ist, dass es derzeit einen großen Unterschied in den von mehreren (> 10) Entwicklern verwendeten Codeformaten gibt, was es für einen Entwickler schwieriger macht, an dem Code eines anderen Entwicklers zu arbeiten. Dieselbe Java-Datei verwendet manchmal drei verschiedene Formate.

Ich glaube also, dass der Vorteil klar ist (Lesbarkeit => Produktivität), aber wäre es eine gute Idee, dies durchzusetzen? Und wenn nicht, warum?

UPDATE
Wir alle verwenden Eclipse und jeder kennt den Plan. Es gibt bereits ein Code-Format, das von den meisten verwendet wird, aber es wird nicht erzwungen, da manche es vorziehen, an ihrem eigenen Code-Format festzuhalten. Aus den oben genannten Gründen würden manche es vorziehen, dies durchzusetzen.

Ich arbeite derzeit an einem Ort, an dem ein Standardcodeformat erzwungen wird und der Code beim Speichern der Datei automatisch formatiert wird, so wie Sie es gerade tun. Als neues Mitglied der Firma stellte ich fest, dass die allgemeinen Formatierungsregeln mir das Gefühl gaben, dass "diese Leute wissen, was sie tun", und ich könnte nicht glücklicher sein. ;) Als verwandte Randnotiz erzwingen wir mit den allgemeinen Formatierungsregeln auch bestimmte, ziemlich strenge Compiler-Warnungseinstellungen in Eclipse, wobei die meisten auf Fehler, viele auf Warnung und fast keine auf Ignorieren gesetzt sind.

Ich würde sagen, dass es zwei Hauptgründe gibt, ein einzelnes Codeformat in einem Projekt durchzusetzen. Das hat zunächst mit der Versionskontrolle zu tun: Wenn jeder den Code identisch formatiert, sind alle Änderungen in den Dateien garantiert aussagekräftig. Nicht mehr nur hier oder da ein Leerzeichen hinzufügen oder entfernen, geschweige denn eine ganze Datei neu formatieren als "Nebeneffekt" des tatsächlichen Änderns von nur ein oder zwei Zeilen.

Der zweite Grund ist, dass dadurch das Ego der Programmierer aus der Gleichung gerissen wird. Wenn jeder seinen Code auf die gleiche Weise formatiert, kann man nicht mehr so ​​leicht erkennen, wer was geschrieben hat. Der Code wird anonymer und gemeinnütziger, sodass sich niemand mehr darum kümmern muss, den Code eines anderen zu ändern.

Das sind die Hauptgründe, es gibt auch andere. Ich finde es beruhigend, dass ich mich nicht mit der Formatierung des Codes befassen muss, da Eclipse dies beim Speichern automatisch für mich erledigt. Es ist sorglos wie das Schreiben von Dokumenten mit LaTeX: Es wird anschließend formatiert und Sie müssen sich beim Schreiben nicht darum kümmern. Ich habe auch in Projekten gearbeitet, in denen jeder seinen eigenen Stil hatte. Dann müssen Sie über dumme und bedeutungslose Themen nachdenken, zum Beispiel, ob es in Ordnung ist, den Code eines anderen in Ihrem eigenen Stil zu ändern, oder ob Sie versuchen sollten, stattdessen dessen Stil zu imitieren.

Das einzige Argument gegen gängige Code-Formatierungseinstellungen, das mir in Ihrem Fall einfällt, ist, dass es sich anscheinend um ein bereits laufendes Projekt handelt, sodass viele unnötige Änderungen in allen Dateien vorgenommen werden und die tatsächlichen Dateiversionen durcheinander gebracht werden. Das beste Szenario ist, wenn Sie die Einstellungen vom Beginn eines Projekts an erzwingen können.

Jeder professionelle Softwareentwickler wird es vorziehen, einen (guten) Standard anzunehmen, anstatt sich auf einen evangelischen Krieg über den Stil einzulassen, und zwar aus den von Ihnen genannten Gründen.

Viele Softwareentwickler führen evangelikale Kriege ......

Abhängig von Ihrer Position im Team und der Teamdynamik können Sie entscheiden, dass ein Sieg im Krieg nicht möglich ist. In diesem Fall ist es am besten, nicht zu starten ...

Ja, das ist gut, wenn alle Entwickler einen Code-Format-Stil haben.

Entwerfen Sie die Codestilformate und importieren Sie diese in alle Eclipse-Entwickler.

Dies wird hilfreich sein, wenn wir mergingCode für das Versionskontrollsystem verwenden.

Was willst du erreichen, wie zurückhaltend willst du sein, um es durchzusetzen (und in der Detailebene werden deine "Regeln" festgelegt), willst du versuchen, es für in verschiedenen Sprachen geschriebenen Code durchzusetzen Wirst du versuchen, es rückwirkend auf bestehenden Code durchzusetzen?

1. Ein gemeinsames Erscheinungsbild von Code kann zwar dazu beitragen, dass Code besser lesbar ist, kann aber auch die Situation verschlimmern, wenn es sich um ein falsches Erscheinungsbild handelt. _hUngarian_lpfstr Notation als Paradebeispiel :)
2. Ich habe "Codestandards" gesehen, die die Anzahl der Leerzeichen in Kommentarblöcken, die alphabetische Reihenfolge der Methodennamen und anderen Unsinn erzwingen. Tu das nicht.
3. Unterschiedliche Sprachen haben unterschiedliche Standards, an die Menschen gewöhnt sind, die Erfahrung in ihrem Gebrauch haben. Einige schreiben diese Standards sogar vor (denken Sie, Python, Cobol, Visual Studio schreiben automatisch C ++ - Konventionen vor, während Java C-Konventionen usw. usw. verwendet).
4. Ändern Sie niemals vorhandenen Code, um ihn zu ändern. Auf diese Weise führen Sie nur neue Probleme ein. Und das bedeutet sowohl Codeabschnitte als auch ganze Quelldateien. Gehen Sie also nicht um das Neuformatieren von vorhandenem Code, wenn jemand eine einzelne Zeile in einer Datei mit 1000 Zeilen ändert.
5. Erfahrene Programmierer können viel produktiver sein, wenn sie nicht die Hälfte der Zeit darüber nachdenken müssen, ob das, was sie schreiben, für das automatische Genehmigungssystem oder den Prüfer "richtig" aussieht. Sie werden auch die Gewohnheit haben, sauberen Code zu schreiben, einfach weil das funktioniert, auch wenn es kleine Unterschiede zwischen ihren natürlichen Stilen gibt.

Es gibt also gute Gründe, einen bestimmten Stil und Standard durchzusetzen, es gibt aber auch gute Gründe, dies nicht (zu) streng zu tun.

Ja, Konsistenz ist eine gute Idee, aus Gründen , andere haben erwähnt .

Ich wollte nur ein paar Punkte hinzufügen, die an keiner anderen Stelle verwendet wurden:

• Oracle hat eine Reihe von Konventionen für Java veröffentlicht, die de facto den Standard darstellen.
  • Wenn Sie diese verwenden, vermeiden Sie Streitigkeiten darüber, welchem ​​Stil Sie folgen müssen.
  • In vielen öffentlichen Bibliotheken und Open Source-Projekten werden diese Konventionen verwendet. Wenn Sie sich also diese ansehen müssen, sollten Sie mit der Formatierung vertraut sein.
  • Der Eclipse-Formatierer verfügt über integrierte Regeln, die diesen Konventionen entsprechen. Dies sollte ebenfalls hilfreich sein.
• Möglicherweise möchten Sie einen Hook in Ihr Quellcodeverwaltungs-Setup integrieren, damit der Code automatisch formatiert wird, bevor er in den Hauptzweig gelangt.
  • Sie können Schlachten mit besonders hartnäckigen Programmierern vermeiden, die sich weigern, dem Standard zu folgen. Sie können sogar während der Arbeit ihre eigene Formatierung verwenden, die später standardisiert wird!
  • Wenn Sie benutzerdefinierte Formatierungseinstellungen verwenden (z. B. ignorieren viele Benutzer die Konvention "maximal 80 Zeichen pro Zeile"), müssen Sie nur an einer Stelle Änderungen vornehmen.

Ich war in einem Team, das das Checkstyle-Plugin verwendete . Anstatt die Standardfunktionen zu verwenden, haben wir ein kleines Komitee aus interessierten Entwicklern gebildet. Wir diskutierten darüber, was fehlte, was übertrieben schien, und hämmerten die Dinge aus. Wir alle haben dabei etwas gelernt und diese Entwicklermuskulatur gestärkt.

(Beispiele für unsere Entscheidungen: 72 Zeichen sind zu klein, aber 120 waren besser. Es ist besser, _ALLCAPS für statische Finale zu verwenden. Es ist eine gute Idee, das einmalige Verlassen einer Funktion zu erzwingen.)

Als wir Code-Reviews hatten, war eine der ersten Fragen: "Haben Sie Checkstyle durchlaufen?" Die Einhaltung der Kodierungsstandards war weitgehend automatisiert und lenkte die Aufmerksamkeit des prüfenden Prüfers auf sich. Es war wunderbar einfach, Checkstyle eine Methodensignatur markieren zu lassen, mit der rechten Maustaste darauf zu klicken und eine Variable in final zu ändern. Es könnte auch die Einrückungen und geschweiften Klammern so korrigieren, dass jeder Code ein ähnliches Erscheinungsbild aufweist. Vermissen Sie einen Javadoc für eine öffentliche Veranstaltung? Checkstyle kennzeichnet die Funktion.

(Das Entfernen von Codegerüchen ist wichtiger als die konsistente Formatierung. Dies ist ein Vorteil von automatisierten Tools.)

Ich würde automatisierte Tools wie Checkstyle weniger als das gleiche Format auferlegen, sondern eher dazu anregen, ein ähnliches Erscheinungsbild zu erzielen. Und wenn Sie Katzen hüten, kann ein automatisiertes Tool dabei helfen, die Fähigkeiten zu verbessern und den Code-Geruch zu reduzieren, ohne zerbrechliche Egos zu verletzen.

Wenn Sie sich an dieselbe IDE halten und einige Formatierungswerkzeuge einbinden möchten, ist dies eine gute Idee, da Sie nicht zu viel Aufwand benötigen. Halten Sie die Regeln einfach, und achten Sie dabei auf Lesbarkeit und nicht auf anale Remanenz . Das sollte der Messstab sein.

Obwohl ein einheitlich geformter Schlammballen besser ist als nur ein Schlammballen, ist es besser, wenn Sie Ihre Zeit damit verbringen, ihn aufzuräumen, anstatt zu wählerisch zu werden, wohin die Klammern führen. Verwandeln Sie sich nicht in einen Manager mit Stecknadelkopf, der das Gefühl hat, seine Arbeit zu erledigen, indem er während einer Codeüberprüfung Leerzeichen zählt und sicherstellt, dass die neuen Deckblätter in den TPS-Berichten enthalten sind .

Persönliche Vorlieben sind genau das und verbessern die Produktion nur selten: https://stackoverflow.com/questions/249432/was-ist-die- Vernunft- hinter- den- unterschiedlichen- Klammerformen

Wenn doch, überwinde es und erledige etwas.

Ich empfehle nachdrücklich, dass Menschen die Formatierung von Code erzwingen und dass geringfügige Verstöße gnädigerweise übersehen oder ausgebessert werden. Gründe hierfür sind kurz

1. Das Gerät macht zum ungünstigsten Zeitpunkt und in der Regel bei Verwendung einer neuen Sprachfunktion einen Fehler. Wie wird es mit Schließungen in Java usw. umgehen? Jalopy hat Probleme mit Aufzählungen von Mitgliedsfunktionen.
2. Ich denke, es ist eine sehr vernünftige Belastung für den Programmierer, Code für das Unternehmen zu erstellen, der aussieht wie Buchungskreis. Ich fand es hilfreich zu erwähnen, dass auf diese Weise Code "hier" formatiert wird und nicht, wie der gesamte Code überall formatiert werden sollte. Ihre vorherige Firma hat möglicherweise einen anderen Weg eingeschlagen, und das ist in Ordnung. Ähnlich wie in der Umgangssprache gibt es für Ihre Codekultur spezifische Redewendungen, die Sie hervorheben möchten.
3. Die Durchsetzung der Codesyntax erfolgt am besten mit Codeüberprüfungen:
   1. Wenn die Formatierung wichtig ist, muss Ihre Organisation Codeüberprüfungen durchführen. Dies ist von großem Vorteil.
   2. Wenn eine Formatierungsregel verletzt wird, kann ein Mensch sie besser betrachten und beurteilen als eine Maschine, wenn die Absicht sauberer vermittelt wird. Dies ist sehr selten, kommt aber gelegentlich vor.

In Bezug auf "Lesbarkeit => Produktivität" werden Sie durch die Codestruktur (z. B. Klassen und Funktionen mit einer Verantwortung) viel schneller als durch die Codeformatierung. Die Formatierung von Code kann hilfreich sein, aber verschiedene Köpfe analysieren Aussagen unterschiedlich - nicht jeder wird "produktiver". Ich möchte die Codestruktur gegenüber der Formatierung verdoppeln, da dies Sie auch dazu bringt, Codeüberprüfungen durchzuführen und das Team dazu zu bringen, sich Gedanken darüber zu machen, wie das Programm funktioniert, und nicht darüber, wie eine einzelne Schleife aussieht.

Ich bin kein großer Fan von Domain Driven Design, aber es ist ein neues Modell, das eine SEHR genau definierte Vorstellung davon hat, wie Code strukturiert sein sollte und Code-Formatierungskonventionen auf natürliche Weise aus einem Domain Driven Design-strukturierten Programm abgeleitet werden. Wieder ... Ich mag DDD nicht, aber es ist ein großartiges Beispiel, weil es so gut definiert ist.

Ich nehme an, dass das Thema dieser Antwort lautet: Codeüberprüfungen durchführen und Formatierungen aus der Kultur und aus dem Überprüfungsprozess heraus fließen lassen.

Wenn Sie vernünftige Entwickler einstellen, ist es im Allgemeinen eine schlechte Idee, ein universelles Code-Format einzuführen. Es ist jedoch eine gute Idee, Code- Richtlinien anzunehmen .

Ich habe noch nie eine Reihe von Code-Formatierungsregeln gesehen, die die Lesbarkeit in allen Fällen optimieren. Ebenso gibt es im Englischen keine 100% anwendbaren Grammatikregeln: Unser Gehirn ist einfach nicht so verkabelt. Verwenden Sie also Richtlinien, aber geben Sie den Entwicklern die Freiheit, diese nach Belieben zu überschreiben.

Davon abgesehen ist es eine gute Regel, die härter ist als die in der Datei / im Projekt bereits vorhandene Codekonvention.

Beachten Sie jedoch, dass die Formatierung wesentlich weniger zur Lesbarkeit beiträgt als lediglich die logische Organisation des Codes. Ich habe viel unlesbaren Spaghetti-Code mit perfekter Formatierung gesehen!

Ich glaube nicht, dass es eine einfache Antwort darauf gibt. Es ist keine Ja oder Nein Frage. Ich glaube zwar, dass Stil und Namenskonventionen in gewissem Maße wichtig sind, aber es ist auch ziemlich einfach, zu viel Zeit damit zu verschwenden, darüber nachzudenken. Am besten mit gutem Beispiel antworten.

Bei einem bestimmten Projekt, an dem ich beteiligt war, gab es überhaupt keine Konventionen. Jeder Entwickler hat seine eigenen Dinge getan. Aufgrund der relativen Unerfahrenheit dieses Teams war es sehr beunruhigend, von einer Klasse zur nächsten zu wechseln. Der Stil war weniger ein Problem als das Problem der Namenskonventionen. Ein Entwickler würde auf UI-Elemente mit schrecklicher ungarischer Notation verweisen (eine alberne Praxis im Zeitalter moderner IDEs), einer würde private Mitglieder auf eine Weise benennen, ein anderer würde sie anders benennen. Sie wussten einfach nie, was Sie sich anschauten.

Umgekehrt verwendete ein Team StyleCop (dies war ein .Net-Projekt) als Teil seines Erstellungsprozesses. Schlimmer ist, dass sie auch die meisten Standardregeln verwendeten. Sie würden also etwas völlig Normales in Bezug auf den Zeilenabstand oder die Platzierung der geschweiften Klammern tun, und der Build würde dadurch kotzen. Es wurde so viel Zeit verschwendet, nur Leerzeichen und Zeilen in Sachen einzufügen, und alle, einschließlich der Typen, die darauf bestanden, StyleCop zu verwenden, machten am Ende fast jedes Commit. Es war eine enorme Zeit- und Geldverschwendung.

Der Punkt, den ich hier mache, ist, dass es nicht die Antwort ist, unflexibel zu sein, aber im Wilden Westen zu sein, ist es auch nicht. Die eigentliche Antwort ist, den Ort zu finden, der am sinnvollsten ist. Meiner Meinung nach besteht dies darin, dass keine automatisierten Tools Dinge überprüfen, aber auch keine Konventionen in den Wind werfen.

Mein Hauptargument gegen den üblichen Codierungsstil ist, dass ein erfahrener Programmierer verwendet wird, um seinen eigenen Stil zu lesen. Sie können die Hand trainieren, um einen bestimmten Stil zu schreiben, aber es ist fast unmöglich, das Auge zu trainieren, um einen Stil zu verstehen, den Sie hassen. Ein Programmierer schreibt einen Teil des Codes einmal und liest ihn dann während der Entwicklung und des Debuggens immer wieder. Wenn er jedes Mal, wenn er seinen eigenen Code liest, Schwierigkeiten hat, ihn zu verstehen, da er gezwungen war, ihn in einem SCHLECHTEN Stil zu schreiben, wird er sehr unglücklich und weniger produktiv sein. Dies ist aus meiner Erfahrung.

Ich bin nicht sehr vertraut mit Eclipse, aber das automatische Formatieren beim Speichern klingt nach einer schrecklichen Idee. Ein Entwickler muss die vollständige Kontrolle über seinen Code haben, unabhängig davon, ob ein Codierungsstil vorgegeben ist oder nicht. Die Operation 'Speichern' darf kein einzelnes Zeichen ohne ausdrückliche Zustimmung des Benutzers ändern.

Wenn Ihr Unternehmen Quellcode verkauft, ist der Codierungsstil wichtiger, aber wenn Sie kompilierten Code verkaufen, ist er viel weniger relevant.

Zu hoffen, dass der Kodierungsstil den ursprünglichen Kodierer weniger unterscheidbar macht und Ego-Kriege verhindert, ist im besten Fall Blödsinn und im schlimmsten Fall schlichtweg dumm. Großartige Programmierer werden unabhängig vom Stil immer eleganten Code produzieren.

Ich bin auch stark dafür, jedem Entwickler den Besitz bestimmter Codeeinheiten zu geben und nicht zuzulassen, dass jeder jeden Code frei berührt. Durch die Entwicklung ganzer Einheiten im Code und die Verantwortung dafür kann der Entwickler stolz auf seine Arbeit werden und ihn daran hindern, beschissenen Code zu entwickeln, da er weiß, dass Fehler zurückkehren werden, um ihn zu jagen.

Schließlich geht jeder, der Pro-Coding-Stil ist, immer davon aus, dass sein eigener Coding-Stil ausgewählt wird, und alle anderen werden folgen. Stellen Sie sich vor, dass der Codierungsstil, den Sie von all Ihren Mitentwicklern am wenigsten mögen, als Standard ausgewählt wird. Sind Sie immer noch für einen imposanten Coding-Stil?

Ein Format, um sie alle zu beherrschen ... ist es wirklich optimal?

Es ist, als würde man das Auto eines anderen fahren ...

Sicher, Sie können in jedes Auto einsteigen und es fahren, aber Sie werden sicherer, komfortabler und weniger unfallanfällig, wenn Sie sich die Zeit nehmen, den Sitz, das Lenkrad und die Spiegel nach Ihren Wünschen einzustellen .

Bei Code wirkt sich die Formatierung auf Ihre Sicherheit beim Lesen und Verstehen des Codes aus. Wenn es zu weit von dem entfernt ist, an das Sie gewöhnt sind, ist mehr geistige Anstrengung erforderlich. Ist es notwendig, dies den Entwicklern aufzuerlegen?

+1 zu allen bisher genannten Vorteilen, aber ...

Die automatische Durchsetzung ist mit Kosten verbunden, die berücksichtigt werden müssen:

-1 auf die Tatsache, dass Code-Formatierer die Ästhetik der Code-Formatierung nicht verstehen. Wie oft hat ein Code-Formatierer einen Kommentarblock zerstört, der in tabellarischer Form angeordnet war? Wie oft haben Sie einen komplexen Ausdruck absichtlich auf eine bestimmte Weise ausgerichtet, um die Lesbarkeit zu verbessern, nur um die automatische Formatierung in etwas zu zerlegen, das "den Regeln folgt", aber weitaus weniger lesbar ist?

Manchmal gibt es Problemumgehungen für diese Dinge, aber Entwickler müssen sich mit wichtigeren Dingen befassen, als den automatischen Formatierer daran zu hindern, den Code zu manipulieren.

Formatierungsregeln haben, aber etwas Freiheit erlauben, gesunden Menschenverstand anzuwenden.

Gute Entwickler sind kreative Menschen, geben ihnen eine künstlerische Lizenz. "Keep it simple" sollte das Mantra des Programmierers sein. Ich habe zwei Regeln:

Regel 1: Geben Sie Variablen / Cursor / Objekte / Prozeduren / SENSIBLE NAMES an. Eindeutige Namen, die Ihrem Code Bedeutung und Verständnis verleihen.

Regel 2: Verwenden Sie Einrückungen, um die Struktur Ihres Codes anzuzeigen.

Das ist es.

Für mich ist der Hauptvorteil eines automatisch angewendeten Formats, dass es uns bei der Änderungsverfolgung und Codeüberprüfung hilft. git (und die meisten anderen Tools zur Versionskontrolle) können Unterschiede zu früheren Versionen der Dateien anzeigen. Durch die Durchsetzung eines gemeinsamen Stils werden Unterschiede zwischen Programmierern minimiert.

Style-Guides ermöglichen auch ein einfacheres programmatisches Parsen von Code für verschiedene Analysezwecke.

Google hat einen Artikel mit dem Titel "Searching for Build Debt: Experiences Managing Technical Debt at Google" veröffentlicht .

Es sind Sprachen, keine Codes. Wir Menschen haben mehr als 6000 Sprachen, also übersetzen wir sie. Wenn Sie also möchten, dass Ihre "Codes" kommunizieren, müssen Sie Ihre Einstellungen vornehmen. Sie sehen, wir Benutzer müssen unsere Datenformate ändern, damit wir unsere Daten nicht verlieren.

Ich würde sagen, dass es nicht ist. Eine gemeinsame Code-Struktur / ein gemeinsames Code-Format in einem Team ist auf jeden Fall eine gute Sache, eine automatische Durchsetzung jedoch nicht. Dies sollte vom Menschen gemacht werden, nicht vom Computer.

Meine größten Probleme mit dem Konzept sind

1. Wenn ich Code in einem Format schreibe und dieser automatisch neu formatiert wird, welcher Anreiz besteht dann, dieses Format tatsächlich zu lernen?
2. Wenn Sie nach diesem vorherigen Punkt das Format nicht kennen, geht der gesamte Punkt der automatischen Formatierung (um das Lesen und Ändern von Code zu vereinfachen) vollständig verloren. Sie müssen sich noch Zeit nehmen, um die Formatierung beim Lesen des Codes zu ermitteln, da Sie dieses Format nicht gelernt haben
3. Ich denke, es wäre eine schreckliche Erfahrung für einen Entwickler, an einem Tag eine Klasse zu schreiben, sie zu schließen und am nächsten Tag zurückzukehren, um zu sehen, dass es völlig anders ist. Das bedeutet, dass nicht nur andere Ihren Code lernen müssen, Sie müssen auch Ihren Code lernen.
4. Es könnte auch zu fauler Codierung führen. Anstatt den Entwickler zu drängen, um das Format zu lernen, können sie in jedem Format unter der Sonne schreiben und es sieht automatisch so aus, wie es alle anderen wollen. Dies geht zurück auf # 2, wo Sie den Stil nicht lernen und ihn trotzdem nicht richtig lesen können.

Nun möchte ich vielleicht sagen, dass es eine gute Idee ist, ein Auto-Format für ein Projekt auszuführen, das vollständig abgeschlossen ist. Dies würde dazu führen, dass jeder Entwickler für das Projekt auf dem gleichen Fuß ist, wenn Sie später Features reparieren / hinzufügen. Während der aktiven Entwicklung halte ich es jedoch für eine sehr schlechte Wahl.

Grundsätzlich gilt: Übernehmen Sie dem Mitarbeiter die Verantwortung, den Stil des Unternehmens zu lernen, und zwingen Sie ihn nicht dazu, etwas zu sein, das es nicht ist.