1)
Wie lautet die Richtlinie zum Deklarieren einer Variablen? Solltest du immer das Schlüsselwort private verwenden, oder ist es in Ordnung, es zu überspringen?
gegen
%Vor% Der einzige Grund, den ich sehe, ist, dass Microsoft eines Tages die Standardzugriffsmodifikatoren in public anstatt in private ändern kann.
Wo steht, dass privat optional ist? Irgendwelche Verweise auf MSDN ?
2) Benennungsrichtlinie für Konstanten?
Ich habe immer Caps verwendet, wenn ich eine Konstante geschrieben habe, aber ein Freund hat mir gesagt, dass dies gegen die Microsoft-Namensrichtlinien verstößt, oder?
%Vor%vs
%Vor%3) Pascal oder Kamel?
Ich persönlich finde Camel einfach hässlich.
1) Das Schlüsselwort private ist optional. Ich bezweifle stark, dass Microsoft jemals die Standardsichtbarkeit von Feldern ändern wird, da dies eine massive, bahnbrechende Änderung wäre (ganz zu schweigen von einer dummen). Es ist nur eine Frage des persönlichen Geschmacks, das Schlüsselwort private wegzulassen.
2) Verwenden Sie keine "Shouty" -Konstanten - befolgen Sie die Konvention des Frameworks und verwenden Sie Pascal Casing (z. B. ThisIsAConstant ist gegenüber THIS_IS_A_CONSTANT vorzuziehen).
Sie könnten an den Designrichtlinien für Entwickler von Klassenbibliotheken
Die offizielle Empfehlung für die Namensgebung von Constants nach den MS-Richtlinien, da sie noch nicht vollständig spezifiziert wurde:
private ist optional, aber zusätzliche Eingabe. Ich mag es, es zu überspringen.
Was die Eigenschaften betrifft, hängt es von Ihren Vorlieben ab und von wem Sie arbeiten. Wenn Sie jedoch Zweifel haben, sehen Sie sich das .NET Framework an und wie diese Konstanten benennen.
Ich bezweifle, dass Microsoft jemals das Standardverhalten für C # -Membervariablen ändern wird. Ich würde Dinge als privat deklarieren, dass Sie privat sein wollen, und explizit Dinge öffentlich machen, dass Sie öffentlich sein wollen, nur für die Klarheit, wenn nichts anderes.
Ich denke, die wichtige Regel für Konstanten besteht darin, einfach eine Namenskonvention zu verwenden, der alle zustimmen und die Sie als Konstante erkennen. Wenn jeder Großbuchstaben mag, dann benutze das. Wenn Sie mehr Standard sein wollen, verwenden Sie Pascal Gehäuse.
Ich persönlich würde es lieben, wenn Konstanten ALL_CAPS wären, wie in einigen anderen Sprachen ... Ich denke, dass es eine schnelle und einfache Möglichkeit ist, Konstanten zu erkennen. Da andere Konstanten in das UsePascalCasing-Framework integriert sind, sollten Sie das auch tun. Konsistenz ist sehr wichtig.
Soweit "Pascal vs. Camel", stoßen Sie auf das gleiche Problem. Wenn Sie nur von sich aus programmieren würden, könnten Sie tun, was immer Sie wollten. Da Sie jedoch ein bereits bestehendes Framework verwenden, sollten Sie aus Konsistenzgründen denselben Stil emulieren. Sobald Sie sich daran gewöhnt haben, werden Sie wahrscheinlich feststellen, dass das Folgen der gleichen Regeln tatsächlich hilft, denn Sie werden sofort wissen, dass etwas ein Parameter oder eine lokale Variable (camelCasing) im Vergleich zu einer Eigenschaft oder Konstante ist (PascalCasing). .
Verwenden Sie Pascal-Hülle in Feldnamen.
Von .NET Framework-Entwicklerhandbuch Namen von Typ-Mitgliedern
Verwenden Sie Pascal Gehäuse für alle Öffentlichkeit Namen von Mitgliedern, Typen und Namespaces bestehend aus mehreren Wörtern.
Beachten Sie, dass diese Regel nicht gilt für Instanzfelder. Aus Gründen, die sind detailliert im Member Design Richtlinien sollten Sie nicht öffentlich verwenden Instanzfelder.
Von .NET Framework-Entwicklerhandbuch Kapitalisierungskonventionen
Beachten Sie den impliziten Standard des Pascal-Gehäuses bei konstanter Benennung.
Verwenden Sie konstante Felder für Konstanten das wird sich niemals ändern.
Der Compiler brennt die Werte von const Felder direkt in den aufrufenden Code. Daher können konstante Werte niemals sein geändert ohne das Risiko des Brechens Kompatibilität.
%Vor%
From Framework Design Guidelines: Konventionen, Idiome und Patterns für wiederverwendbare .NET-Bibliotheken, zweite Ausgabe Seite 161
Ich kann keinen Hinweis darauf finden, ob Sie private Felder mit dem Begriff privat dekorieren sollen. das ist eher eine interne Stilwahl, die ich annehmen würde. Was auch immer Sie auswählen, Sie wollen konsistent bleiben.
1) Ich neige dazu, privat zu verwenden, nur um explizit zu sein, aber es gibt wirklich keine Notwendigkeit, ich denke,
2) Es stimmt, Microsoft empfiehlt, keine Caps für Konstanten zu verwenden.
Die Namenskonventionen von Microsoft für Typ-Member finden Sie hier
Hier ist ein kostenloses eBook mit C # und VB .net Codierungsrichtlinien, es ist sehr gut
Persönlich mag ich es jedoch, explizit festzulegen, wann etwas privat ist, um es lesbar zu machen. Tatsächlich bin ich so daran gewöhnt, dass ich verwirrt werde, wenn ich es nicht sehe. Was Konstanten betrifft, verwende ich PascalCasing.
Sie könnten an den Designrichtlinien für Entwickler von Klassenbibliotheken
Sie können Ihre Frage nicht direkt beantworten, aber Sie wären vielleicht an Microsofts StyleCop interessiert. Dies ist ein Werkzeug zur Analyse Ihres Quellcodes in Bezug auf Stil- und Konsistenzregeln. Standardmäßig gelten die Gestaltungsrichtlinien von Microsoft.
1) Das Schlüsselwort %code% ist optional. Ich bezweifle stark, dass Microsoft jemals die Standardsichtbarkeit von Feldern ändern wird, da dies eine massive, bahnbrechende Änderung wäre (ganz zu schweigen von einer dummen). Es ist nur eine Frage des persönlichen Geschmacks, das Schlüsselwort %code% wegzulassen.
2) Verwenden Sie keine "Shouty" -Konstanten - befolgen Sie die Konvention des Frameworks und verwenden Sie Pascal Casing (z. B. %code% ist gegenüber THIS_IS_A_CONSTANT vorzuziehen).
Die offizielle Empfehlung für die Namensgebung von Constants nach den MS-Richtlinien, da sie noch nicht vollständig spezifiziert wurde:
Ich bezweifle, dass Microsoft jemals das Standardverhalten für C # -Membervariablen ändern wird. Ich würde Dinge als privat deklarieren, dass Sie privat sein wollen, und explizit Dinge öffentlich machen, dass Sie öffentlich sein wollen, nur für die Klarheit, wenn nichts anderes.
Ich denke, die wichtige Regel für Konstanten besteht darin, einfach eine Namenskonvention zu verwenden, der alle zustimmen und die Sie als Konstante erkennen. Wenn jeder Großbuchstaben mag, dann benutze das. Wenn Sie mehr Standard sein wollen, verwenden Sie Pascal Gehäuse.
private ist optional, aber zusätzliche Eingabe. Ich mag es, es zu überspringen.
Was die Eigenschaften betrifft, hängt es von Ihren Vorlieben ab und von wem Sie arbeiten. Wenn Sie jedoch Zweifel haben, sehen Sie sich das .NET Framework an und wie diese Konstanten benennen.
1) Wie lautet die Richtlinie zum Deklarieren einer Variablen? Solltest du immer das Schlüsselwort %code% verwenden, oder ist es in Ordnung, es zu überspringen?
%Vor%gegen
%Vor%Der einzige Grund, den ich sehe, ist, dass Microsoft eines Tages die Standardzugriffsmodifikatoren in %code% anstatt in %code% ändern kann.
Wo steht, dass privat optional ist? Irgendwelche Verweise auf MSDN ?
2) Benennungsrichtlinie für Konstanten?
Ich habe immer Caps verwendet, wenn ich eine Konstante geschrieben habe, aber ein Freund hat mir gesagt, dass dies gegen die Microsoft-Namensrichtlinien verstößt, oder?
%Vor%vs
%Vor%3) Pascal oder Kamel?
Ich persönlich finde Camel einfach hässlich.
privat ist optional, Sie können es also überspringen.
Wenn Ihre Klasse jedoch eine Mischung aus privaten, geschützten und öffentlichen Datenelementen aufweist, empfiehlt es sich, aus Gründen der Lesbarkeit anzugeben, dass ein Mitglied privat ist.
Auch private Feldnamen sollten in camel case vorkommen, optional mit Präfix _ oder m_:
%Vor%Ich persönlich würde es lieben, wenn Konstanten ALL_CAPS wären, wie in einigen anderen Sprachen ... Ich denke, dass es eine schnelle und einfache Möglichkeit ist, Konstanten zu erkennen. Da andere Konstanten in das UsePascalCasing-Framework integriert sind, sollten Sie das auch tun. Konsistenz ist sehr wichtig.
Soweit "Pascal vs. Camel", stoßen Sie auf das gleiche Problem. Wenn Sie nur von sich aus programmieren würden, könnten Sie tun, was immer Sie wollten. Da Sie jedoch ein bereits bestehendes Framework verwenden, sollten Sie aus Konsistenzgründen denselben Stil emulieren. Sobald Sie sich daran gewöhnt haben, werden Sie wahrscheinlich feststellen, dass das Folgen der gleichen Regeln tatsächlich hilft, denn Sie werden sofort wissen, dass etwas ein Parameter oder eine lokale Variable (camelCasing) im Vergleich zu einer Eigenschaft oder Konstante ist (PascalCasing). .
Verwenden Sie Pascal-Hülle in Feldnamen.
Von .NET Framework-Entwicklerhandbuch Namen von Typ-Mitgliedern
Verwenden Sie Pascal Gehäuse für alle Öffentlichkeit Namen von Mitgliedern, Typen und Namespaces bestehend aus mehreren Wörtern.
Beachten Sie, dass diese Regel nicht gilt für Instanzfelder. Aus Gründen, die sind detailliert im Member Design Richtlinien sollten Sie nicht öffentlich verwenden Instanzfelder.
Von .NET Framework-Entwicklerhandbuch Kapitalisierungskonventionen
Beachten Sie den impliziten Standard des Pascal-Gehäuses bei konstanter Benennung.
Verwenden Sie konstante Felder für Konstanten das wird sich niemals ändern.
Der Compiler brennt die Werte von const Felder direkt in den aufrufenden Code. Daher können konstante Werte niemals sein geändert ohne das Risiko des Brechens Kompatibilität.
%Vor%
From Framework Design Guidelines: Konventionen, Idiome und Patterns für wiederverwendbare .NET-Bibliotheken, zweite Ausgabe Seite 161
Ich kann keinen Hinweis darauf finden, ob Sie private Felder mit dem Begriff privat dekorieren sollen. das ist eher eine interne Stilwahl, die ich annehmen würde. Was auch immer Sie auswählen, Sie wollen konsistent bleiben.
Hier ist ein kostenloses eBook mit C # und VB .net Codierungsrichtlinien, es ist sehr gut
Persönlich mag ich es jedoch, explizit festzulegen, wann etwas privat ist, um es lesbar zu machen. Tatsächlich bin ich so daran gewöhnt, dass ich verwirrt werde, wenn ich es nicht sehe. Was Konstanten betrifft, verwende ich PascalCasing.
1) Ich neige dazu, privat zu verwenden, nur um explizit zu sein, aber es gibt wirklich keine Notwendigkeit, ich denke,
2) Es stimmt, Microsoft empfiehlt, keine Caps für Konstanten zu verwenden.
Die Namenskonventionen von Microsoft für Typ-Member finden Sie hier
@Dan Diplo # Verwenden Sie kein Präfix für Mitgliedsvariablen (, m, s_, usw.). Wenn Sie # zwischen lokalen Variablen und Member-Variablen unterscheiden möchten, sollten Sie "this." In C # und "Me." In VB.NET verwenden.
Das ist höchst strittig. Präfix hilft Intellisense: Sie setzen Präfix Zeichen und erhalten nur eine Liste von lokalen privaten Instanzfeldern. Mit diesem. Sie erhalten eine vollständige Liste, die aus Methoden, Feldern, Eigenschaften, Ereignissen usw. besteht.
Beachten Sie auch folgendes Beispiel:
%Vor%In C # wird standardmäßig die größtmögliche Sichtbarkeit verwendet. Ohne einen Modifikator:
Da es eine gute Idee ist, die Sichtbarkeit so gut wie möglich einzuschränken, versuche ich immer den Modifikator zu verlassen, wo die Standardsichtbarkeit alles ist, was ich brauche. Dies macht diejenigen Member, die sind nicht der Standard offensichtlicher, was hilft mir aufmerksam zu machen, ob sie wirklich so sichtbar sein müssen.
Für Konstanten würde ich es vorziehen, sie in ihre eigenen Klassen zu setzen, so dass das Format ClassName.ConstantName es offensichtlich macht, was sie sind.
Im Allgemeinen folge ich den Designrichtlinien für die Entwicklung von Klassenbibliotheken .
Sie könnten auch an Microsofts internen Richtlinien für die interne Codierung für das .NET Framework interessiert sein, wie enthüllt von Brad Abrams in seinem Blog :
Befolgen Sie alle .NET Framework-Designrichtlinien für interne und externe Member. Zu den Highlights gehören:
@Dan Diplo # Verwenden Sie kein Präfix für Mitgliedsvariablen (, m, s_, usw.). Wenn Sie # zwischen lokalen Variablen und Member-Variablen unterscheiden möchten, sollten Sie "this." In C # und "Me." In VB.NET verwenden.
Das ist höchst strittig. Präfix hilft Intellisense: Sie setzen Präfix Zeichen und erhalten nur eine Liste von lokalen privaten Instanzfeldern. Mit diesem. Sie erhalten eine vollständige Liste, die aus Methoden, Feldern, Eigenschaften, Ereignissen usw. besteht.
Beachten Sie auch folgendes Beispiel:
%Vor%In C # wird standardmäßig die größtmögliche Sichtbarkeit verwendet. Ohne einen Modifikator:
Da es eine gute Idee ist, die Sichtbarkeit so gut wie möglich einzuschränken, versuche ich immer den Modifikator zu verlassen, wo die Standardsichtbarkeit alles ist, was ich brauche. Dies macht diejenigen Member, die sind nicht der Standard offensichtlicher, was hilft mir aufmerksam zu machen, ob sie wirklich so sichtbar sein müssen.
Für Konstanten würde ich es vorziehen, sie in ihre eigenen Klassen zu setzen, so dass das Format ClassName.ConstantName es offensichtlich macht, was sie sind.
Im Allgemeinen folge ich den Designrichtlinien für die Entwicklung von Klassenbibliotheken .
Tags und Links c# variables naming-conventions constants private