Empfohlene .NET / C # -Codierungsstandards? [geschlossen]

Welche Codierungsstandards halten Sie für wichtig für .NET / C # -Projekte? Dies kann alles sein, was mit geschweiften Klammern, Abständen und Pedanterie zu tun hat. Oder es könnten grundlegendere Fragen wie die zu vermeidenden Namespaces in .NET Framework, Best Practices für Konfigurationsdateien usw. sein.

Vermeiden Sie es, einen Beitrag zu erstellen, der lediglich die Folge eines anderen ist. Zum Beispiel wäre es in Ordnung, wenn sich ein Beitrag auf geschweifte Klammern konzentrieren würde. Wir brauchen keine zwei, um einen Stil gegen den anderen zu unterstützen. Die Idee ist nicht, für Ihren Haustierstandard zu stimmen, sondern zu konkretisieren, woran Sie bei der Erstellung von Standards denken sollten.

Hier finden Sie den offiziellen Microsoft-Leitfaden zu Codierungsstandards für .NET Framework Version 4.0.

Wenn Sie die ältere Version für 1.1 wollen, versuchen Sie es hier .

Ich folge dem nicht unbedingt mit einem "T", wie sie sagen. Im Zweifelsfall ist dies jedoch der beste Ausgangspunkt, um mit dem aktuellen .NET-Framework konsistent zu sein, was es für alle einfacher macht, unabhängig davon, ob sie für Ihr bestimmtes Projekt neu sind oder nicht.

Vielleicht möchten Sie einen Blick auf StyleCop werfen . Sie können es sogar in einige Build-Systeme integrieren, sodass Stilfehler den Build beschädigen. Die Standardeinstellungen stimmen größtenteils mit den Empfehlungen von MS für Richtlinien überein (wie von anderen veröffentlicht).

Sie können auch die Standardregeln ändern.

Richtlinien von Microsoft:

• .NET - http://msdn.microsoft.com/en-us/library/czefa0ke.aspx
• C # - http://blogs.msdn.com/brada/articles/361363.aspx

Wir haben dies in unserem Büro übernommen. Es wurde von Lance Hunt geschrieben und ist ziemlich umfassend:

http://weblogs.asp.net/lhunt/pages/CSharp-Coding-Standards-document.aspx

Beginnen Sie mit FxCop . Es informiert Sie über Verstöße gegen Best Practices in Ihrem vorhandenen Code.

Ich versuche, einen gemeinsamen Satz von Stilen aus verschiedenen Quellen auszuwählen. Einige, die vorher nicht erwähnt wurden:

• die Dokumentation aus den C # -Codierungsrichtlinien - letzte Aktualisierung im Jahr 2010
• IDesign C # Coding Standard - letzte Aktualisierung im Jahr 2008
• Philips Healthcare - C # -Codierungsstandard - letzte Aktualisierung im Jahr 2009
• Encodo C # Handbuch - letzte Aktualisierung im Jahr 2009

Ich muss die von SSW (einem australischen Beratungsunternehmen) zur Verfügung gestellten Standards empfehlen.

Nicht nur Codierung, sondern Projektmanagement usw. Eine unglaublich wertvolle Ressource.

http://www.ssw.com.au/ssw/standards/default.aspx

Methoden sollten kurz sein

Die meisten Methoden sollten die meisten Felder in einer Klasse verwenden.

Wähle deine Namen gut aus.

Lesen Sie zB das Clean Code- Buch

Ich verwende die folgenden Anwendungen, um einen Codierungsstandard neben Camelback-Regeln, Methodennamen usw. beizubehalten.

GhostDoc - Fügt am Anfang jeder Methode einen automatisch generierten Kommentar hinzu. Die Anwendung bietet eine gute erste Zusammenfassung der Methode. (frei)

http://submain.com/products/ghostdoc.aspx

Resharper - Code-Analyse und Refactoring http://www.jetbrains.com/resharper/

StyleCop - Als letzte Bereinigung vor dem Einchecken in TFS. (frei)

http://code.msdn.microsoft.com/sourceanalysis

Ich hasse etablierte Codierungsstandards. Sie alle wollen Ihnen entweder sagen, dass Sie keine dummen Fehler machen sollen, oder wie Sie Ihren Code auf die eine oder andere Weise formatieren sollen. All das sind Kleinigkeiten.

Ich meine, sie sagen Ihnen, wie viele Leerzeichen zwischen Operatoren gesetzt werden müssen, wie Ihre Variablen in Groß- und Kleinschreibung geschrieben werden müssen, welche Präfixe im ungarischen Stil verwendet werden sollen (z. B. _ für Mitglieder), widersprüchliche Hinweise (z. B. Sie können keine Klasse Cxyz aufrufen, müssen es aber Rufen Sie ein Interface auf (Ixyz), wie Sie Ihren Code gestalten (setzen Sie Ihre Variable oben in die Klasse oder unten in die Klasse).

Alle sind im Großen und Ganzen nutzlos.

Was für das Schreiben von effektivem, wartbarem und lesbarem Code wichtig ist, wird in diesen Standards nie erwähnt.

Zum Beispiel: Platzieren Sie Ihre Variablen oben oder unten in Ihrer Klasse? Nun, wen interessiert das - was zählt, ist, wenn Sie Ihre Variablen nach Funktionsbereichen gruppieren. Das ist wichtig (Sie werden es wissen, wenn Sie jemals 20 Variablen gesehen haben, die über den Ort verstreut sind).

Sie fordern Sie auf, Ihre geschweiften Klammern an bestimmten Stellen anzubringen. Große Sache! Ich kann Code sowohl in K & R- als auch in ANSI-Klammern lesen, es spielt keine Rolle. Was wichtig ist, ist, ob alle Fensterklassen in irgendeiner Weise voneinander unterschieden sind (z. B. mit einem Suffix mit Form oder Dlg oder was auch immer), damit Sie sehen können, welche Dateien Fenstercode enthalten und welche gewöhnliche Objekte sind.

Sachen wie diese sind weitaus wichtiger als die kleinen Punkte, die Standards normalerweise enthalten. Ich weiß nicht, warum sie sich so entwickelt haben, aber oft sind es nur eine Menge Regeln, die einer effektiven und produktiven Codierung im Wege stehen.

Meine Standards konzentrieren sich mehr auf die Organisation von Code und Dateien. Wir haben bestimmte Standards, die sich darauf beziehen, wo Dateien gefunden werden. Zum Beispiel können sich die Nicht-Entwickler eines unserer Projekte ansehen und sofort die benötigten Dokumentationsdateien abholen. In ähnlicher Weise versuchen wir, den Projektcode so praktisch wie möglich zu gestalten (Hinweis: Praktisch, nicht in einer stark verbotenen Weise, die unter Umständen nicht immer angemessen ist) kann nach Bedarf geändert werden.

Kurz gesagt - sie sind dort zu helfen Sie uns zusammenarbeiten, nicht als eine Reihe von restriktiven Regeln , die immer haben gefolgt werden.

Warnung: Pragmatismus unten - Die Frage scheint formuliert zu sein, um eine Debatte über den "richtigen" Stil der geschweiften Klammer usw. auszulösen. Ich bin nicht damit einverstanden, Zeit mit diesem Unsinn zu verschwenden.

1. Installieren Sie ReSharper , behalten Sie die Standardeinstellungen bei und tun Sie, was immer es sagt.

2. Profit - Jeder in Ihrem Team wird denselben Stil haben, der den Microsoft-Richtlinien verdammt nahe kommt, und nur in einigen Punkten davon abweichen, in denen die Resharper-Standards das widerspiegeln, was in der Industrie tatsächlich verbreiteter ist und (möglicherweise) Verbesserungen sind.

Je weniger Zeit Ihr Team damit verbringt, ein riesiges Dokument oder Buch zu erstellen und zu referenzieren oder über die curly bracesund andere Irrtümer zu streiten, desto mehr Code wird erstellt. ReSharper erzwingt die Benennung und den Stil während der Eingabe. Getan. Ende der Debatte. Es gab nichts mehr zu streiten. Weitermachen.

Das heißt, eine Lektüre des klassischen Code Complete hilft ihnen, die Gründe für Codierungsstandards zu verstehen, und bietet viele nützliche Hinweise zur effektiven Vermittlung von Bedeutungen durch den Code - etwas, was ein Normdokument oder ein Inspektionsprogramm nicht kann.

Wenn Sie die Möglichkeiten von Resharper erweitern möchten , fügen Sie StyleCop mit dem StyleCop for ReSharper-Plug-In hinzu. Wie bereits erwähnt, gibt es einige geringfügige Konflikte zwischen den MS-Richtlinien und den ReSharper-Standardeinstellungen. Ich würde nur mit ReSharper auf diese gehen. Aber egal auf welcher Seite Sie sich befinden, speichern Sie die Ergebnisse einfach in der ReSharper-Konfigurationsdatei, teilen Sie sie mit Ihrem Team und fertig.

(Nein, ich bin kein bezahlter Shill für ReSharper, sondern nur ein zufriedener Kunde. Zusätzlich zu seinen vielen anderen Funktionen verarbeitet es grundlegende Stilprobleme kostengünstiger als jedes Standarddokument oder Codeüberprüfungssystem - und überlässt den Kopf für wichtige Dinge .)