Mein Team (von mir bin ich das jüngste und jüngste Mitglied) hat sich in nur etwa einem Jahr von drei auf neun Entwickler vergrößert. Unser primäres Produkt hat an Komplexität zugenommen, und wir sind dabei, uns ein Jahr lang an Silverlight zu portieren / neu zu schreiben. In der Vergangenheit wurde kein spezieller Stil / Standard durchgesetzt.
Ich schlug meinem Chef vor, dass jetzt ein guter Zeitpunkt wäre, solche Standards zu implementieren. Ich habe IDesigns Dokument an ihn weitergegeben und er mag die Idee. Er hat 2 Bedenken.
Dies ist ein großes zu absorbierendes Dokument. Mein Gedanke hier ist, einen abgespeckten Spickzettel für die gebräuchlichsten Gegenstände zu entwickeln, denen wir wahrscheinlich begegnen werden, mit dem Verständnis, dass der IDesign-Standard der "Meister" ist und alles, was nicht in der abgespeckten Version abgedeckt ist, betrachtet werden sollte im "Master" -Dokument.
Was ist der beste Weg, dies zu erzwingen? Es geht nicht darum, zu diktieren; es geht darum zu versuchen, die Leute dazu zu bringen, sich an einen bestimmten Standard zu gewöhnen. Es gibt mindestens 2 Leute im Team, die sich seit einigen Jahren auf den aktuellen Nicht-Standard entwickeln. Um dieses Problem anzugehen, würde ich gerne sehen, ob es ein Tool gibt, das konfiguriert werden kann, um diese Standards durchzusetzen, oder zumindest vor "Verstößen" des Standards zur Kompilierungszeit oder zur Entwurfszeit warnt. Ich fand Microsoft StyleCop, aber von dem, was ich feststellen konnte, ist es nicht konfigurierbar und ist so eingerichtet, dass es dem Microsoft-Standard folgt, der nicht vollständig mit dem von IDesign übereinstimmt.
Jede Eingabe über Werkzeuge oder die Vorgehensweise, die ich betrachte, wären willkommen.
Eine Kombination aus ReSharper, FxCop / StyleCop (es gibt eine Möglichkeit, benutzerdefinierte Regeln zu definieren, zumindest für FxCop), klare Code-Richtlinien und monatliche Reviews sollten die Arbeit für ein Team von neun Leuten erledigen, denke ich. Wenn jemand die Regeln bricht, hast du keine Chance, eine Peitsche zu benutzen:)
Regelmäßige Code-Überprüfungen wären ein guter Weg zu gehen ...
Ich habe festgestellt, dass Entwickler besser auf direkte Diskussionen zu einem bestimmten Standard reagieren, anstatt sie nur einem Werkzeug zu überlassen.
Die Verwendung eines Tools zusammen mit Codeüberprüfungen sollte gut sein.
Es ist schwierig, die Bedeutung von Codierungsstandards zu übertreiben. Der Schlüssel ist, dass Sie eine konsistente Code-Basis haben sollten, die jeder schnell lesen und verstehen kann. Es ist weniger wichtig, welche Standards du wählst (solange sich jeder anmeldet) - aber wenn du einen Standard auswählst, der weit verbreitet ist, dann müssen weniger Entwickler ihren Stil anpassen. Die Microsoft-Designrichtlinien für Entwickler von Klassenbibliotheken sind meine Favoriten (und sehr ReSharper freundlich).
Ein Kollege von mir ( Howard van Rooijen ) und sein Open-Source-Team entwickeln das ausgezeichnete StyleCop für ReSharper , zeigt Ihnen Stilverletzungen in Echtzeit, indem Sie sie während der Eingabe hervorheben! Es gab eine aktuelle Version was herzlich empfohlen wird.
Notizen aus meiner Erfahrung bekommen Buy-in auf Coding-Standards bei meiner derzeitigen Firma (kleine Entwickler von mehreren Projekten, jeder mit 1-6 Programmierer pro Stück; wir sind in erster Linie C ++, aber ich denke, die Antworten werden immer noch gelten):
Ein Code-Review Spickzettel ist eine großartige Idee. Passen Sie es an Ihre Organisation an (z. B. was leicht zu übersehen ist oder falsch liegt), und aktualisieren Sie es so, wie Sie es tun (einmal im Monat, kommen Sie zurück und entfernen Sie Dinge, die auf andere Weise erzwungen werden). Wenn du ein Wiki hast, füge Links zu "warum" für jeden Punkt ein, wenn du kannst!
Teilen Sie Ihre Rezensionen auf . Einige Commits begehen formelle Reviews, andere nicht. Wir verwenden ein paar Typen:
Automatisieren und drücken, ziehen Sie nicht nützliche Informationen. Wir verschicken Berichte von unserem Buildserver - normalerweise werden sie einmal pro Commit erstellt (abhängig davon, wie ausgelastet). Diese Berichte können z.B. die Unterschiede zwischen einem aktuellen Gimpel PC-Lint Lauf und dem letzten. Dies betrifft die "zu viele Informationen" Sorge: Sie erhalten nur die Warnungen / Fehler Sie sind möglicherweise verantwortlich für, zusammen mit der Beschreibung. Wenn die Informationen eingegrenzt und leicht zu verstehen sind, verwenden sie sie als Lernwerkzeug.
Ich kann dieses Bit nicht genug betonen: Schwitz nicht die kleinen Sachen . (Siehe Punkt # 0 des wunderbaren C ++ Coding Standards Buches.)
Schließlich fördern Sie die Teilnahme und mutieren Ihren Codierungsstandard im Laufe der Zeit. (Hier kann ein Wiki nützlich sein.) Wenn jemand einen legitimen Grund hat, einem Teil des Standards nicht zu folgen (entweder haben sie etwas Besseres, oder es ist zu viel Pita, um zu folgen), höre zu und antworte. Wenn Menschen tatsächlich aktiv zum Standard beitragen und ihn verstehen, anstatt ihn nur zu übergeben, werden Sie viel bessere Antworten bekommen.
Versuchen Sie ReSharper, es kann Ihren Code zu Ihrem Stil formatieren. Auch die gesamte Lösung auf einmal umformatieren.
Vielen Dank für Ihren Rat. Ich würde gerne mehr hören. Wie es passiert, als ich in Resharper wie empfohlen von Ilya Ryzhenkov suchte ich zufällig den IDesign-Standard erneut herunterladen , die in einer Zip-Datei mit einem Link zu diesem Blogeintrag geliefert wird. Der gute Teil ist standardmäßig der Standard, den ich verwenden möchte. Es ist billig (lesen Sie kostenlos, wenn Sie nicht spenden) und ich bin ein großer Fan von Code-Rush! und Refactor , also habe ich schon den DXCore geladen!
Ich habe gerade ein Blog geschrieben, in dem ich ReSharper und StyleCop zusammen benutze und es durch Continuous Integration (mit NAnt) durchsetze.
Sehen Sie, was Sie davon halten. Es funktioniert sehr gut für uns. Ein paar Murren wie bei aktuellen ich scheitern die Build, wenn eine einzelne Codeverletzung eingeführt wird. Wir haben jedoch Zehntausende von Verstößen (meist in altem Legacy-Code), also ist meine Antwort, einen von ihnen zu bereinigen, und das sollte Code besser nicht schlechter werden.
Ich habe das als Antwort bekommen, Hitlers Nightly Build Fails: Ссылка
Suchen Sie etwas, was kürzer ist. Entwickler haben so viel daran zu erinnern, dass es Zeitverschwendung ist, von ihnen zu erwarten, dass sie sich mehr als eine Seite mit Regeln merken. Selbst wenn du ihnen einen Spickzettel gibst, es sei denn, dies ist das offizielle und einzige Dokument, landest du bei Entwicklern, die für den Rest ihren eigenen Stil erfinden.
Es empfiehlt sich, eine einfache Konvention zu befolgen, die einem großen, komplizierten Dokument folgt, das nicht befolgt wird.
Als Nebensache, haben Sie sichergestellt, ordnungsgemäß von innen aus dem Team?
Meistens haben alle Code-Standards, die ich gesehen habe, dumme Sachen wie alle if-Anweisungen verlangt, die geschweifte Klammern enthalten müssen, die Dinge wie
ruinieren %Vor%Weil solche Sachen jetzt drei Zeilen brauchen und deshalb nicht geschrieben werden (oder wenn das der Fall ist, verhindern, dass der Programmierer herausfinden kann, was die Methode macht).
Wenn Ihr Team einen kontinuierlichen Build hat (z. B. mit Hudson ), können Sie Stilbeschränkungen erzwingen, indem Sie den Build abbrechen oder ihn instabil machen wenn jemand Änderungen festlegt, die gegen die Stilrichtlinien verstoßen. Hudson hat ein Verstoß Plugin, das mit Tools wie Checkstyle und StyleCop verwendet werden kann.
Ohne zu wissen, wie Ihre Konfigurationsmanagement-Konfiguration aussieht, sollten Sie zunächst nach Tools suchen, die in Ihr Versionskontrollsystem integriert werden und Code evaluieren, bevor der Code für das Repository festgeschrieben wird. Ich habe dies mit unserem SVN-Setup getan und habe es auch mit CVS gemacht ... es ist bis zu einem gewissen Grad effektiv, weil es den Entwickler zwingt, "korrekten" Code zu übermitteln und das Repository ordentlich zu halten. Ein einfaches Beispiel hierfür wäre das Zurückweisen eines Commits, wenn der Benutzer keine spezifischen Informationen in der Übergabenachricht (d. H. Fehler #, Projektaufgabe usw.) bereitgestellt hat.
Neben den Tools müssen Sie einen Weg finden, um den Entwicklern den Wert eines Codierungsstandards darzustellen. Hört sich einfach an, aber das war bisher der schwierigste Teil für mich. Zeigen Sie den Entwicklern, dass ein wenig Aufwand einen großen Beitrag leisten kann, wenn es um die Pflege einer Codebasis geht.
In unserer Firma verwenden wir Referenzkarten für C #. Referenzkarten werden in PowerPoint mit 2 Folien erstellt. Ein Frontslide und Backslide (2-Seiten-Druck). Jede Folie hat 3 Spalten (Zeitungssetup). Zwischen jeder Säule wird 1 cm Weiß gemacht, um Falten zu erhalten.
Platzieren Sie die wichtigsten Aspekte der vollständigen Kodierungsrichtlinie des Unternehmens in den 2 Folien (zum Beispiel haben wir: Kodierungsstil, Namespaces & amp; Lösungsstruktur, Namenskonventionen).
Sie haben sich für IDesigns Out-of-the-Box-Codierungsrichtlinien entschieden. Vielleicht ist es einfacher für Sie, den MS-Codierungsstil zu erlernen, aber das ist Ihre Entscheidung. Die meisten Entwickler sind mit den MS-Richtlinien vertraut und daher leichter zu erlernen.
Mit TFS und VS 2010, mit einer c # -Basis, machen wir das so:
Wir verwenden den unbearbeiteten idesign-Standard als unseren Code-Standard auf Papier.
Wir pflegen eine Reihe von Code-Analysen und Style Cop-Definitionen, die wir bei Release-Builds mit Null-Toleranz ausführen.
Wir unterhalten auch eine kompatible Resharper-Root-Definition, mit der Entwickler ihren Code schnell formatieren können, während sie damit arbeiten. Dies erleichtert ihren Workflow, da sie nicht mehr auf die SA / CA-Warnungen von den Build-Time-Checks warten müssen.
Wir erlauben dem Entwickler, die Root-Definition zu überschreiben.
Standardkonflikte, die von diesen beiden Ebenen nicht erfasst werden, werden dann im Reviewprozess gefunden und gelöst. Was in Bewertungen nicht gefunden wird, wird in der Codepflege gefunden.
Tags und Links c# standards coding-style