Glauben Sie, ein Software-Unternehmen Entwickler eine Codierung Stil aufzwingen sollte? [geschlossen]

https://stackoverflow.com/questions/145508

02-07-2019
|

Frage

Wenn Sie denken, es sollte nicht erklären, warum.

Wenn ja, wie sollten tief die Richtlinien Ihrer Meinung nach sein? Zum Beispiel soll Einzug von Code aufgenommen werden?

Lösung

Ich denke, ein Team (anstatt ein Unternehmen ) müssen sich auf eine Reihe von Leitlinien für angemessen einheitlichen Stil vereinbaren. Es macht es einfacher für die Wartung.

Wie tief? So flach wie Sie vereinbaren können. Je kürzer und klarer ist es umso wahrscheinlicher ist es, dass alle Teammitglieder zustimmen kann und wird sich daran halten.

Andere Tipps

Sie wollen alle zu lesen und Code in üblichen Weise zu schreiben. Es gibt zwei Möglichkeiten, wie Sie dies erreichen:

Klon, der ein einzelner Entwickler mehrmals und sicherstellen, dass sie alle durch die gleiche Ausbildung gehen. Hoffentlich sollten sie alle in der Lage die gleiche Code-Basis zu schreiben.
Geben Sie Ihren bestehenden Entwickler explizite Anweisung auf dem, was Sie benötigen. Tabs oder Leerzeichen für die Einrückung. Wo Klammern sitzen. Wie zu kommentieren. Versionskontrolle verpflichtet Richtlinien.

Je mehr Sie lassen nicht definiert ist, desto höher ist die Wahrscheinlichkeit, einer der Entwickler auf Stil kollidieren wird.

Das Unternehmen sollte verhängen, dass einiger Stil gefolgt werden soll. Was für Stil, der ist und wie tief die Richtlinien sind, sollte in der Gesellschaft gemeinsam von der Entwickler-Community entschieden werden.

Ich würde auf jeden Fall legt die Leitlinien fest auf Klammern, Einzüge, Namensgebung etc ... Sie schreiben Code für Lesbarkeit und Wartbarkeit. Nehmen Sie immer an jemand anderes wird Ihr Code zu lesen. Es gibt Werkzeuge, die automatisch auf magischen Code formatieren, und Sie können Mandat, dass jeder das Tool verwendet.

Wenn Sie auf .Net Blick auf StyleCop, FxCop und ReSharper

Denken Sie, ein Software-Unternehmen Entwickler eine Codierung Stil aufzwingen sollte?

Nicht in einem top-down. Entwickler in einem Software-Unternehmen auf einem gemeinsamen Codierung Stil zustimmen sollten.

Wenn ja, wie tief sollten die Richtlinien Ihrer Meinung nach sein?

Sie sollten nur die Unterschiede von bekannten Konventionen beschreiben, versuchen, die Abweichung minimal zu halten. Dies ist einfach für Sprachen wie Python oder Java, etwas verschwommen für C / C ++, und fast unmöglich, Perl und Ruby.

Zum Beispiel Vertiefung des Codes enthalten sein sollte?

Ja, es macht Code viel besser lesbar. Halten Vertiefung konsistent in Bezug auf Räume vs Tabs und (wenn Sie entscheiden sich für Räume) Anzahl von Leerzeichen. Auch einigen sich auf einen Rand (z.B. 76 Zeichen oder 120 Zeichen) für lange Leitungen.

Ja, aber im Rahmen des Zumutbaren.

Alle modernen IDEs bieten Ein-Tastendruck Code ziemlich Druck, so dass der "Vertiefung" Punkt ist ziemlich irrelevant, meiner Meinung nach.

Was ist wichtiger ist Best Practices zu etablieren: zum Beispiel, verwenden Sie so wenig „out“ oder „ref“ Parameter wie möglich ... In diesem Beispiel haben Sie zwei Vorteile: verbessern die Lesbarkeit und auch viele Fehler beheben (viel out-Parameter ist ein Code Geruch und wahrscheinlich Refactoring werden soll).

darüber hinaus zu gehen ist, in meiner ehrlichen Meinung, ein bisschen „anal“ und unnötig ärgerlich für die Devs.

Guter Punkt von Hamish Smith:

Stil ist ganz anders als am besten Praktiken Methoden Ausübungen. Es ist eine Schande, dass ‚Codierung Standards' neigen dazu, die beide zu rollen zusammen. Wenn die Menschen könnten die halten Stil Teil auf ein Minimum und konzentrieren sich auf die Best Practices, würde wahrscheinlich mehr Wert hinzuzufügen.

Ich glaube nicht, ein Entwickler-Team haben Stil Leitlinien sollten sie in der Regel folgen müssen. Es gibt Ausnahmen, zum Beispiel die Verwendung von <> vs. „“ in # include-Anweisungen aber diese Ausnahmen sollten aus der Not kommen.

Der häufigste Grund, warum ich Menschen zu erklären verwenden hören, warum Artrichtlinien notwendig sind, ist, dass Code in einem gemeinsamen Stil geschrieben einfacher ist, dass Code in individuellem Stil geschrieben zu halten. Ich stimme dir nicht zu. Ein professioneller Programmierer wird nicht verzetteln werden, wenn sie sehen so aus:

for( int n = 0; n < 42; ++42 ) {
 // blah
}

... wenn sie verwendet werden, dies zu sehen:

for(int n = 0; n < 42; ++42 )
{
 // blah
}

Außerdem habe ich es eigentlich leichter zu pflegen Code in einigen Fällen gefunden, wenn Sie den Programmierer, der den ursprünglichen Code ihren Stil durch einfaches Erkennen schrieb identifizieren kann. Gehen sie fragen, warum sie das Gizmo in einem solchen gewundenen Weg in 10 Minuten statt verbringen den größten Teil des Tages herauszufinden, die sehr technischen Grund, warum sie umgesetzt haben etwas unerwartet. Zwar haben die Programmierer sollten den Code kommentierten ihre Argumentation zu erklären, aber in der realen Welt Programmierer oft nicht.

Wenn es sich schließlich Joe dauert 10 Minuten backspacing & bewegte seine geschweiften Klammern, so dass Bill 3 weniger Sekunden Blick auf den Code verbringen, hat es wirklich zu jeder Zeit sparen zu Bill etwas machen tun, die nicht natürlich zu ihm kommt?

Ich glaube, eine einheitliche Code-Basis ist wichtig. Es erhöht die Wartbarkeit des ur-Code. Wenn jeder die gleiche Art von Code erwartet, können sie leicht lesen und verstehen.

Außerdem ist es nicht viel Aufwand ist IDEs heutigen gegeben und ihre automatische Formatierung Fähigkeiten.

P. S: Ich habe diese Unsitte meine Zahnspange auf der nächsten Zeile setzen :). Niemand sonst scheint es zu mögen

Ich denke, dass die Programmierer der Lage sein sollten, um den Stil von anderen Programmierern anzupassen. Wenn ein neuer Programmierer nicht in der Lage ist, sich anzupassen, bedeutet, dass in der Regel, dass der neue Programmierer zu stur ist, den Stil des Unternehmens zu verwenden. Es wäre schön, wenn wir alle können unser eigenes Ding zu tun; aber wenn wir alle Code entlang einiger Bast-Richtlinie, macht es die Fehlersuche und Wartung einfacher. Dies gilt allerdings nur, wenn der Standard ist gut durchdacht und nicht zu restriktiv.

Während ich mit allem, was nicht einverstanden ist, enthält dieses Buch einen ausgezeichneten Ausgangspunkt für Standards

Die beste Lösung wäre für IDEs solche Formatierung als Meta-Daten zu betrachten. Zum Beispiel kann die geschweifte Klammer Öffnungsposition (aktuelle Zeile oder nächste Zeile), Vertiefung und weißen Raum um Betreiber sollten ohne Änderung der Quelldatei konfigurierbar sein.

Meiner Meinung nach glaube ich es mit Standards und Styleguides sehr notwendig ist. Denn wenn der Code-Basis wächst wollen Sie es konsequent haben.

Als Randbemerkung, das ist, warum ich Python lieben; weil es erlegt bereits eine ganze Reihe von Regeln, wie Sie Ihre Anwendungen und so strukturieren. Vergleichen Sie das mit Perl, Ruby-oder was auch immer, wo Sie eine extreme Freiheit haben (was in diesem Fall nicht so gut ist).

Es gibt viele gute Gründe für die Standards, wie die Anwendungen entwickelt werden, zu definieren und die Art und Weise der Code aussehen sollte. Zum Beispiel, wenn jeder verwendet den gleichen Standard eine automatische Stil Prüfung als Teil des Projekt CI verwendet werden könnte. Unter Verwendung des gleichen Standards Lesbarkeit des Codes verbessern und hilft, die Spannung zwischen den Teammitgliedern über Refactoring den gleichen Code auf unterschiedliche Weise zu reduzieren. Deshalb:

der durch das jeweilige Team entwickelte gesamten Code folgen sollte genau den gleichen Standard.
die für ein bestimmtes Projekt entwickelt All Code sollte genau den gleichen Standard folgen.
Es ist wünschenswert, dass die Teams auf dem gleichen Unternehmen gehören, den gleichen Standard verwenden.

In einem Outsourcing-Unternehmen könnte eine Ausnahme für ein Team für einen Kunden arbeitet gemacht werden, wenn der Kunde einen Standard ihrer eigenen erzwingen will. In diesem Fall übernimmt das Team des Standard des Kunden, die mit dem von ihrer Firma verwendet unvereinbar sein könnte.

Wie andere schon erwähnt haben, ich glaube, es durch Technik sein muss oder durch das Team -. Das Unternehmen (das heißt Geschäftseinheiten) nicht in dieser Art von Entscheidung einbezogen werden

Aber eine andere Sache, die ich hinzufügen möchte, ist keine Regeln, die von Tools erzwungen werden umgesetzt sollten und nicht von Menschen. Worst-Case-Szenario, IMO, ist einige übereifrige Grammatik-Snob (ja, wir existieren, ich weiß das, weil wir unsere eigenen riechen) schreibt eine Dokumentation eine Reihe von Code-Richtlinien umreißt die absolut niemand liest tatsächlich oder folgt. Sie veralten im Laufe der Zeit, und als neue Leute in das Team aufgenommen werden und alte Leute verlassen, sie einfach veralten.

Dann entsteht ein Konflikt, und jemand in der unbequemen Lage versetzt von jemandem anderen über Codierung Stil zu konfrontieren, die - diese Art der Konfrontation von Werkzeugen und nicht von Menschen getan werden soll. Kurz gesagt, diese Methode der Durchsetzung ist die am wenigsten wünschenswert, meiner Meinung nach, weil es viel zu einfach zu ignorieren und einfach bittet Programmierer zu argumentieren, über dumme Dinge.

ist

Eine bessere Option (wieder, IMO) ist Warnungen bei der Kompilierung geworfen haben (oder so ähnlich), so lange, wie Ihre Build-Umgebung dies unterstützt. Es ist nicht schwer, dies in VS.NET zu konfigurieren, aber ich bin nicht bewusst anderen Entwicklungsumgebungen, die ähnliche Merkmale aufweisen.

Style Richtlinien sind extrem wichtig, ob sie für die Gestaltung und Entwicklung ist, weil sie die Kommunikation und Leistung der Menschen zu beschleunigen, die gemeinsam arbeiten (oder auch allein, nacheinander, als wenn die Stücke eines alten Projektes Abholung). nicht ein System der Konvention innerhalb eines Unternehmens, die sich nur die Leute zu fragen sein, wie unproduktiv, wie sie können. Die meisten Projekte erfordern die Zusammenarbeit, und auch diejenigen, die unsere Programmierung Koteletts nicht anfällig für unseren natürlichen Wunsch sein kann und aktuell halten auszuüben. Unser Wunsch in die Quere kommt unserer Konsistenz zu lernen -. Was eine gute Sache an und für sich ist, kann aber einen neuen Mitarbeiter verrückt zu versuchen, die Systeme zu lernen, sie in auf herspringt

Wie jedes andere System, das für gut gemeint und nicht das Böse, die wirkliche Macht der Führung liegt in den Händen der Menschen. Die Entwickler selbst bestimmen, was die wesentlichen und nützlichen Teile sind und dann, hoffentlich, sie verwenden.

Wie das Gesetz. Oder die englische Sprache.

Style Guides sollte so tief sein, wie sie sein wollen - wenn es in dem Brainstorming kommt, soll es enthalten sein. Es ist seltsam, wie Sie die Frage formuliert, denn am Ende des Tages gibt es keine Möglichkeit einen Style Guide zu „verhängen“, weil es nur ein GUIDE.

RTFM, aufzulesen dann die guten Sachen und wieder mit ihm.

Ja, ich glaube, Unternehmen sollten. Entwickler müssen möglicherweise die Codierung Stil gewöhnen, aber meiner Meinung nach ein guter Programmierer sollte in der Lage sein, mit jeder Art der Programmierung zu arbeiten. Wie Midhat sagte: Es ist wichtig, eine einheitliche Code-Basis zu haben,

Ich denke, das für Open-Source-Projekte auch wichtig ist, gibt es keinen Supervisor, Ihnen zu sagen, wie Sie Ihren Code zu schreiben, aber viele Sprachen haben Spezifikationen, wie die Benennung und Organisation des Codes sollte. Dies ist sehr hilfreich, wenn die Komponenten in Ihr Projekt Open-Source-Integration.

Sicher, sind Richtlinien gut, und es sei denn, es ungarische Notation schlecht verwendet wird (ha!), Wird es wahrscheinlich Konsistenz verbessern und andere Leute Code erleichtern das Lesen. Die Leitlinien sollten nur Richtlinien sein, obwohl, nicht strenge Regeln für Programmierer erzwungen. Sie könnten mir sagen, wo meine Zahnspange setzen oder nicht Namen wie Temperatur zu verwenden, aber was Sie nicht tun können, ist mir Räume Werte um Index in Array Klammern zu haben, zu zwingen (sie habe einmal versucht, ...)

Ja.

Coding Standards sind ein gemeinsamer Weg von diesem Code innerhalb einer bestimmten Organisation zu gewährleisten wird das Prinzip der geringstenen Überraschung folgen:. Konsistenz in Normen ausgehend von Variablennamen zu Einbuchtung geschweifte Klammer Verwendung

Coders ihren eigenen Stil und ihre eigenen Standards, die nur eine Code-Basis herzustellen, die widersprüchlich, verwirrend und frustrierend zu lesen, vor allem bei größeren Projekten.

Diese die Coding-Standards für ein Unternehmen sind für I zu arbeiten. Sie sind gut definiert, und, während es mir dauerte eine Weile, um sich daran zu gewöhnen, bedeutete, dass der Code von uns allen, und einheitlich den ganzen Weg durch lesbar war.

Ich glaube Coding-Standards innerhalb eines Unternehmens wichtig sind, wenn kein gesetzt sind, da Auseinandersetzungen zwischen Entwicklern und Fragen sein, mit Lesbarkeit werden.

Mit dem Code Uniform des ganzen Weg durch einen besseren Code zu dem Endbenutzer präsentiert (so sieht es aus, als ob es von einer Person geschrieben -, die, von einer Endbenutzer Sicht sollte - die betreffende Person „das Unternehmen sein "und es hilft auch bei der Lesbarkeit im Team ...

Ein gemeinsamer Codierungsstil fördert Konsistenz und macht es einfach für andere Menschen leicht zu verstehen, pflegen und die gesamte Codebasis erweitern, nicht nur ihre eigenen Stücke. Es macht es auch leichter für neue Leute schneller um den Code zu lernen. Daher sollte jedes Team ein Richtlinien auf, wie der Code geschrieben werden soll.

Wichtige Richtlinien enthalten (in keiner bestimmten Reihenfolge):

Leerzeichen und Vertiefung
Standard Kommentare - Datei, Klasse oder Methode Header
Namenskonvention - Klassen, Interfaces, Variablen, Namespaces, Dateien
Code Anmerkungen
Projektorganisation - Ordnerstrukturen, Binärdateien
Standardbibliotheken - was für Vorlagen, Generika, Container und so weiter zu verwenden,
Fehlerbehandlung - Ausnahmen HRESULTs, Fehlercodes
Threading und Synchronisation

Auch vorsichtig sein, Programmierer, die nicht können oder nicht, um den Stil des Teams anpassen, egal wie hell sie sein könnte. Wenn sie nicht von einem der Team-Regeln spielen werden sie wahrscheinlich nicht so gut von anderen Team Regeln spielen.

Ich würde zustimmen, dass die Konsistenz der Schlüssel. Sie können nicht hübsch-Druck auf IDE verlassen den Tag zu retten, weil einige Ihrer Entwickler keine IDE mögen können, und weil, wenn Sie durch eine Code-Basis von Tausenden von Quelldateien sind Schleppen, es ist einfach durchführbar nicht recht zu drucken Sie alle Dateien, wenn Sie sie anfangen zu arbeiten, und führen Sie danach eine Roll-back so Ihre VCS nicht versucht, alle Änderungen zu übernehmen zurück (Verstopfung Repository mit unnötigen Aktualisierungen, die Belastung jeder).

Ich würde zumindest empfiehlt die Standardisierung der folgenden (in der Reihenfolge ihrer Bedeutung):

Whitespaces (es ist am einfachsten, wenn Sie einen Stil wählen, die den automatischen ziemlich Druck von einigem gemeinsamen Werkzeug entspricht)
Naming (Dateien und Ordner, Klassen, Funktionen, Variablen, ...)
Kommentar (mit einem Format, die automatische Dokumentation Generation erlaubt)

Meine Meinung:

sind einige Grundregeln gut, wie es jeder hilft, den Code zu lesen und verwalten
sind zu viele Regeln schlecht, wie es die Entwickler stoppt mit klarer Weise innovativen Code Auslegen
Individueller Stil kann nützlich sein, die Geschichte einer Code-Datei zu bestimmen. Diff / Schuld Tools verwendet werden können, aber der Hinweis ist immer noch nützlich

Modern IDEs können Sie eine Formatierungsvorlage definieren. Wenn es ein Corporate-Standard ist, dann eine Konfigurationsdatei entwickeln, die die Formatierung alle Werte definiert, die Sie interessieren und stellen Sie sicher, dass jeder läuft die Formatierungs, bevor sie in ihrem Code zu überprüfen. Wenn Sie noch strenger darüber sein wollen könnten Sie einen commit für Ihr Versionskontrollsystem fügen Sie den Code einrücken, bevor sie angenommen wird.

Ja in Bezug auf einen gemeinsamen Benennungsstandard sowie ein gemeinsames Layout Klassen und Code-Behind-Dateien verwenden. Alles andere ist offen.

Jedes Unternehmen sollte. Konsistente Codierung Stil sorgt für eine höhere Lesbarkeit und Wartbarkeit der Code-Basis über ganze Ihr Team.

Der Shop ich nicht funktioniert eine einheitliche Codierung Standard haben, und ich kann sagen, dass wir (als Team) leiden erheblich von dem. Wenn es keinen Willen von den Individuen (wie bei einigen meiner Kollegen) ist, hat der Teamleiter der Faust auf den Tisch zu schlagen und eine Form von standardisierten Code-Richtlinien auferlegen.

Immer Sprache hat allgemeine Standards, die von der Gemeinschaft verwendet werden. Sie sollten kann auf die Sprache, die von anderen Personen gehalten wird jene so gut wie möglich, so dass der Code folgen, aber es gibt keine Notwendigkeit diktatorische darüber zu sein.

Die Schaffung eines offiziellen Standard ist falsch, weil ein Unternehmen Standard-Codierung in der Regel zu starr ist, und nicht in der Lage mit der allgemeinen Bevölkerung fließen, um die Sprache.

Wenn Sie ein Problem mit einem Teammitglied wirklich da draußen in Codierstil sein zu müssen, das ist eine hervorragende Sache für die Gruppe sanft vorschlagen ist keine gute Idee, an einem Code-Review.

Coding Standards: JA. Aus Gründen bereits in diesem Thread abgedeckt.

Styling-Standards: NO. Ihre lesbar ist mein verwirrender Ramsch, und umgekehrt. Gut zu kommentieren und Code Factoring hat einen viel größeren Nutzen. Auch GNU indent.

Ich mag Ilyas Antwort, weil es die Bedeutung der Lesbarkeit enthält, und die Verwendung der kontinuierlichen Integration als Durchsetzungsmechanismus. Hibri erwähnt FxCop, und ich denke, seine Verwendung in dem Build-Prozess als eines der Kriterien für die Bestimmung, ob ein Build nicht passiert oder flexibler und effektiver wäre als nur ein Standard-Dokumentation.

Ich bin damit einverstanden, dass ganz Coding-Standards angewandt werden sollen, und dass es fast immer auf Teamebene sein soll. Allerdings gibt es ein paar Ausnahmen.

Wenn das Team ist das Schreiben von Code, der von anderen Teams verwendet werden soll (und hier meine ich, dass andere Teams an der Quelle suchen müssen, nicht nur sie als Bibliothek verwenden), dann gibt es Vorteile für die Herstellung von gemeinsamen Standards für alle Teams es zu benutzen. Ebenso, wenn die Politik des Unternehmens häufig ist für Programmierer von einem Team zum anderen zu bewegen, oder ist in einer Position, wo ein Team häufig Code aus einem anderen Team wieder verwenden will, dann ist es wahrscheinlich am besten Standards in der gesamten Gesellschaft zu verhängen.

Es gibt zwei Arten von Konventionen.

Typ A Konventionen: "Bitte tun dies, es ist besser"

und Typ B:. „Bitte auf der rechten Seite der Straße fahren“, während es in Ordnung ist, auf der anderen Seite zu fahren, solange jeder die gleiche Art und Weise funktioniert

Es gibt nicht so etwas wie ein eigenes Team. Die gesamte Code in einer guten Firma verbunden ist, irgendwie, und Stil sollte konsistent sein. Es ist einfacher, sich einen neuen Stil zu gewöhnen als zwanzig verschiedene Stile .

Auch ein neuer Entwickler sollte die Praktiken der bestehenden Code-Basis respektieren können, und ihnen zu folgen.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow