Warum sollte ich nicht das Präfix meine Felder? [geschlossen]

https://stackoverflow.com/questions/659552

20-08-2019
|

Frage

Ich habe noch nie ein Fan von ungarischen Notation gewesen, habe ich fand es immer ziemlich nutzlos, wenn Sie einige wirklich niedrigen Level-Programmierung tun, aber in jedem C ++ Projekt habe ich auf einer Art ungarische Notation Politik gearbeitet wurde durchgesetzt und damit die Verwendung einiger ‚nicht-wirklich-ungarischen‘ Präfixe als m_ für Felder, s_ für Statik, g_ für Globals und so weiter.

Bald wurde mir klar, wie viel nutzlos es in C # war und allmählich begann alle meine alten Gewohnheiten fallen zu lassen ... aber die ‚m_‘ Sache. Ich benutze immer noch den m_ Präfix auf private Feldern, weil ich es wirklich sehr nützlich finden, um in der Lage, zwischen den Parametern, Einheimischer und Feldern zu unterscheiden.

Die Konventionen für Felder Seite bei MSDN Namensgebung sagt, ich soll nicht, aber es sagt nicht, warum (die Art und Weise wie die Google-Konventionen im allgemeinen dazu neigen, ihre Verschreibungen zu rationalisieren).

Gibt es Gründe, warum soll ich nicht, oder ist es nur eine Frage des Stils. Wenn es letzteres ist, sind Präfixe im Allgemeinen ein schlechter Stil und kann ich erwarten, negative Reaktionen von anderen Menschen auf der Code-Basis zu arbeiten?

Lösung

Ich mag den underbar Präfix für Mitgliederfelder. Meistens mag ich es, weil auf diese Weise sind alle meine Mitgliederfelder vor meiner Methoden im Assistenten Leiste am oberen Rand des Bildschirms in alphabetischer Reihenfolge angezeigt.

Assistenten

Andere Tipps

Wenn Sie soll:

Wenn Sie Ihr Projekt Code-Richtlinien sagen, Sie sollten

Wenn Sie sollten nicht:

Wenn Sie Ihr Projekt Code-Richtlinien sagen, Sie sollten nicht

Wenn Sie irgendwelche Richtlinien noch nicht haben, Sie sind frei zu wählen, was Sie oder Ihr Team wollen und sich am wohlsten fühlen. Persönlich, wenn C ++ Codierung Ich neige dazu, m_ für Mitglieder zu verwenden, es hilft. Wenn in anderen Sprachen Codierung, insbesondere solche ohne echte Klassen (wie Javascript, Lua) ich nicht.

Kurz gesagt glaube ich nicht, dass es ein „Recht“ und eine „falsche“ Art und Weise.

Die automatisch implementierte Eigenschaft Funktion in C # 3.0 besteht weniger eine Notwendigkeit für diese Konvention der einen oder der anderen Seite. Statt zu schreiben

string m_name;
public string Name { get { return m_name; } }

oder

string _Name;
public string Name { get { return _Name; } }

(oder eine andere Konvention), können Sie jetzt schreiben

public string Name { get; private set; }

Da Sie nicht mehr den expliziten Zusatzspeicher Variable benötigen, Sie müssen nicht mehr für ihn mit einem Namen kommen; also diese ganze Diskussion zu vermeiden.

Offensichtlich ist dieses Argument gilt nicht, wenn Sie wirklich explizite Unterstützung Speicher benötigen wie die Validierung durchgeführt.

Wie einige angespielt haben, die MS-Richtlinien sagen:

Sie kein Präfix für Feldnamen verwenden. Verwenden Sie zum Beispiel nicht g_ oder s_ zu unterscheidet statisch im Vergleich zu nicht-statischen Felder aus.

ich zufällig mit diesem zustimmen. Präfixe machen Sie Ihren Code hässlich aussehen und Abfallraum mit belanglosen Zeichen. Having said that, ist es oft üblich Felder zu verwenden, um Eigenschaften zu sichern, wo sowohl das Feld und die Eigenschaft die gleichen Namen (mit dem privaten Bereich zu seinem Kamel Fall und die Eigenschaft ist pascal Fall) haben würden. In VB, funktioniert das nicht, da VB nicht abhängig ist. In diesem Szenario empfehle ich die Verwendung eines einzigen _ Präfix. Nicht mehr und nicht weniger. Es sieht nur saubere, IMHO.

Ich habe mit m_, s_ experimentiert, nur _, und kein Präfix überhaupt. Ich habe über die Verwendung nur abgerechnet _ für alle statischen und Instanzvariablen. Ich finde es nicht wichtig, statische Variablen von Instanzvariablen zu unterscheiden. In der Theorie klingt es gut, in der Praxis ist es nicht ein Problem erstellen.

Ein Kollege machte einmal ein überzeugendes Argument, alle Präfixe zu beseitigen, haben wir versucht, es an einem Projekt und es funktionierte besser als ich erwartet hatte. Ich trug es mich auf mein nächstes Projekt und wurde ärgerlich, dass es „stört“ mit Intellisense. Wenn Sie die folgende Situation haben

int foo;
public int Foo
{
  get { return foo; }
}

Starten foo eingeben werden sowohl die Instanz-Variable und die Eigenschaft vorschlagen. Prefixing die Variable mit einem Unterstrich entfällt die lästige Doppel Vorschlag, so wechselte ich _ nur auf die Verwendung zurück.

Ich versuche, die MSDN .NET Bibliothek Richtlinien . Sie verfügen über einen Richtlinien Abschnitt zu nennen.

Offensichtlich sind diese sekundären zu einem Projekt-Richtlinien.

Ich ziehe Eigenschaft Träger Felder markieren mit Unterstrichen (obwohl wie bereits erwähnt .NET 3.0+ die Notwendigkeit, durch automatische Eigenschaften reduziert), aber nicht den „m“. Zum einen stellt sie es an der Spitze der InteliSense Liste, wenn ich komme, sie zu nutzen.

Ich gebe zu, dass ich über die Leitlinien für MSDN bürsten-up, können die Dinge so schnell in diesen Tagen ändern.

Mit Tools wie ReSharper gibt es wirklich keinen Grund für Präfixe. Auch wenn Sie kurze Methoden schreiben, sollten Sie in der Lage sein, sehr schnell zu sagen, wo die var herkommt. Schließlich, ich denke, ich würde nicht wirklich sehen die Notwendigkeit, einen Unterschied zwischen einer statischen oder nicht zu sagen, weil wieder resharper auf rote Linie geht es, wenn Sie versuchen, etwas zu tun, sind Sie nicht in der Lage. Auch ohne resharper sind Sie wahrscheinlich durch den Compiler gespeichert.

Ich habe immer das Präfix Membervariablen mit m _ und statischen Variablen mit s _ aus den gleichen Gründen, die Sie angeben. Einige Leute Präfix Membervariablen mit einem Unterstrich, aber ich habe immer gefunden, das ein bisschen seltsam aussehende (aber das ist nur eine persönliche Präferenz).

Die meisten Leute, die ich mit der Nutzung arbeiten die m_ / s_ Präfix. Ich weiß nicht wirklich denke, dass es wichtig ist zu viel, was Sie verwenden, solange Sie konsistent sind.

Ich benutze sie nie. Es fördert schlampig Codierung. Die MSDN Code-Richtlinien, das ist, wo es ist.

Hier sind ein paar Gründe zu verwenden _ (und nicht m _).

(1) Viele BCL Jungs tun obwohl es Benennung der MS. (Sehen Sie sich ihre Blog rel="nofollow.) Diese Jungs den Rahmen zu schreiben, so haben sie einige gute Gewohnheiten wert Kopieren. Einige der nützlichsten Beispielcode auf MSDN wird von ihnen geschrieben, und so nutzt den Unterstrich-Konvention. Es ist ein de-facto-Industriestandard.

(2) Ein einzelner Unterstrich ist eine merkliche dennoch unaufdringliche Art und Weise Methode und Klasse-Ebene Variablen eindeutig zu machen, indem Sie einfach die Quelle zu lesen. Es hilft den Menschen neu zu verstehen (oder alten) Code auf einen Blick , wenn es zu lesen. Ja, Sie können den Mauszeiger über diese in einer IDE, um zu sehen, aber wir sollten nicht gezwungen werden. Vielleicht möchten Sie es in einem Texteditor lesen, oder ich wage es zu sagen, auf dem Papier.

(3) Einige sagen, dass Sie keinen Präfix benötigen als Methoden kurz sein, und später benötigt, wenn Sie das Feld in eine automatisch implementierte Eigenschaft ändern können. Aber in der realen Welt Methoden sind so lange, wie sie sein müssen, und es gibt wichtige Unterschiede zwischen den Feldern und Eigenschaften (zum Beispiel Serialisierung und Initialisierung).

Fußnote: Der „m“ für Mitglied in m_ ist hier in unserer Nutzung überflüssig, aber es war niedriger Fall, weil eine der Ideen, in viele dieser alten Namenskonventionen, dass die Typnamen mit Groß- und Instanznamen gestartet wurde gestartet mit Kleinbuchstaben. Das gilt nicht in .NET so ist es doppelt redundant. Auch ungarische Notation war manchmal nützlich, mit alten C-Compiler (zum Beispiel integer oder Zeiger Gießen und Arithmetik), sondern auch in C ++ seine Nützlichkeit vermindert wurde, wenn sie mit Klassen zu tun.

Es gibt einen wichtigen Unterschied zwischen C ++ und C #: Werkzeugunterstützung. Wenn Sie die festgelegten Richtlinien (oder gemeinsame Variationen) folgen, werden Sie ein tiefes Niveau der Tool-Unterstützung erhalten, die C ++ nie hatte. die Standards Nach ermöglicht Tool tiefer Refactoring zu tun / umbenennen Operationen als Sie sonst in der Lage sein würden. ReSharper tut dies. Halten Sie sich also mit einem der etablierten Standards.

Wie @John Kraft erwähnt, gibt es keine „richtige“ Antwort. MattJ ist die nächste - sollten Sie Ihre Firma Stil-Richtlinien immer folgen. Wenn in Rom, und so weiter.

Was meine persönliche Meinung, da es hier genannt wird, ich stimme, dass Sie m_ ganz fallen lassen.

Ich glaube, die beste Art ist, in der alle Mitglieder PascalCased sind, unabhängig von Sichtbarkeit (das bedeutet auch private Mitglieder), und alle Argumente camelCased. Ich nicht brechen diesen Stil.

Ich kann den Wunsch verstehen Eigenschaft Sicherungsspeicher Feld Präfix; schließlich müssen Sie zwischen dem Feld und der Eigenschaft, rechts unterscheiden? Ich bin damit einverstanden, Sie müssen. Aber verwenden Sie einen Post-fix.

Statt m_MyProperty (oder sogar _MyProperty, die ich je gesehen habe und sogar einmal eine Zeit gefördert), verwenden MyPropertyValue. Es ist einfacher zu lesen und zu verstehen, und - was noch wichtiger ist - es zu Ihrem ursprünglichen Eigenschaftsnamen in intellisense der Nähe ist.

Schließlich, das ist der Grund, warum ich ein Postfix bevorzugen. Wenn ich MyPropertyValue mit Intellisense Sie zugreifen möchten (in der Regel) Typ „My <down-arrow> <tab>“, da bis dahin bist du nah genug, dass nur MyProperty und MyPropertyValue auf der Liste stehen. Wenn Sie m_MyProperty mit IntelliSense zugreifen möchten, müssen Sie den Typ „m_My <tab>“.

Es geht um Tastendruck Wirtschaft, meiner Meinung nach.

ich das nie tun, und der Grund dafür ist, dass ich [versuchen] halte meine Methoden kurz. Wenn ich das ganze Verfahren auf dem Bildschirm sehen können, kann ich die params sehen, ich die Einheimischen sehen und so kann ich sagen, was von der Klasse gehört und was ist ein param oder ein lokales.

Ich nennen normalerweise meine params und Einheimischen eine besondere Notation, aber nicht immer. Ich bin nichts, wenn nicht im Widerspruch. Ich verlasse mich auf die Tatsache, dass meine Methoden kurz sind und versuchen, sie zu halten, zu tun, X, Y und Z, wenn sie nur X tun.

Wie auch immer, das ist meine zwei Cents.

Wenn ich mit vi oder Emacs zum Bearbeiten von Code bin stecken, nimmt mein IDE Pflege von Differential-Display von Mitgliedern für mich so selten benutze ich spezielle Konventionen. Das gilt auch für deren Schnittstellen zu I oder Klassen mit C prefixing.

Jemand, bitte erklären Sie den .NET-Stil I-Präfix auf Schnittstellen. :)

, was ich bin es gewohnt ist, dass private Eigenschaften kleine underscone f.ex „string _name“ bekam. die Öffentlichkeit bekam man „Namen“. und die Eingangsgrößen in Methoden bekam kleinen Buchstaben "Leere MyMethod (string name)".

Wenn Sie static const bekommen oft mit großen Buchstaben geschrieben. static const MYCONST = "hmpf".

ich nie ungarischen Warzen verwenden, wenn ich die Wahl habe. Es ist zusätzliche Eingabe und vermittelt keine aussagekräftigen Informationen. Jedes gutes IDE (und ich definiere „gut“ basierend auf dem Vorhandensein dieser Funktion unter anderem) ermöglicht es Ihnen, eine andere Syntax haben Hervorhebung für statische Elemente, beispielsweise Mitglieder, Mitgliederfunktionen, Typen, usw. Es gibt keinen Grund zu Krempel Ihre Code mit Informationen, die von den IDE zur Verfügung gestellt werden kann. Dies ist eine logische Folge nicht, Ihren Code mit kommentierten-out altem Code unübersichtlich, weil Ihr Versionierungssystem soll für diese Sachen verantwortlich sein.

Der beste Weg ist auf einem Standard mit Ihren Kollegen zustimmen, und auch daran halten. Es muss nicht unbedingt die Methode sein, die für alle am besten funktionieren würde, nur auf ein Verfahren einverstanden ist wichtiger als welche Methode Sie eigentlich einig.

Was wir für unseren Code-Standard gewählt ist _ als Präfix Variablen für Element zu verwenden. Einer der Gründe dafür war, dass es macht es einfach, die lokalen Variablen in der Intellisense zu finden.

Bevor wir auf diesem Standard vereinbart habe ich ein anderes. Ich habe keinen Präfix überhaupt, und schrieb this.memberVariable im Code zu zeigen, dass ich ein Mitglied Variable wurde mit.

Mit der Eigenschaft Stenografie in C # 3, finde ich, dass ich viel weniger explizite Membervariablen verwendet werden.

Die nächste Sache zu offiziellen Richtlinien ist StyleCop , ein Werkzeug von Microsoft, die automatisch analysieren Ihre Quelldateien und erkennen Verletzungen von dem empfohlenen Codierung Stil und kann innerhalb von Visual Studio und / oder automatisierte Builds wie MSBuild ausgeführt werden.

Wir verwenden es auf unseren Projekten und es hilft, Code-Stil und Layout konsequenter zwischen Entwicklern zu machen, obwohl gewarnt werden, es braucht ganz ein bisschen gewöhnungsbedürftig!

Um Ihre Frage zu beantworten -. Es keine ungarische Notation erlauben, noch irgendwelche Vorsilben wie m_ (in der Tat ist es nicht die Verwendung von Unterstrichen überhaupt erlauben)

Ich benutze nicht diese Art mehr. Es wurde entwickelt, um Ihnen zu helfen, schnell zu sehen, wie Variablen verwendet wurde. Die neueren Entwicklungsumgebungen können Sie diese Informationen finden Sie, indem Sie die Maus über die Variable schweben. Die Notwendigkeit dafür ist weggegangen, wenn Sie diese neueren Tools verwenden.

Es könnte auch einige Einsicht sein, von nachgelesen werden C ++ Coding Standards ( Sutter, Herb und Alexandrescum Andrei , 2004). Artikel # 0 mit dem Titel „Den Kleinkram nicht schwitzen (Oder:. Wissen Sie, was nicht zu standardisieren).“.

Sie zu dieser speziellen Frage berühren, ein wenig mit den Worten: „Wenn Sie nicht auf Ihrer eigene Namenskonvention entscheiden können, versuchen ... Private Membervariablen Diesembeispiel _ ...“ (Denken Sie daran, den Einsatz von Unterstrich unterliegt ganz bestimmte Regeln in C ++).

Doch bevor es immer, sie betonen, ein gewisses Maß an Konsistenz „... das Wichtigste ist, eine Regel nicht zu setzen, sondern nur mit dem Stil bereits im Einsatz in der Datei konsistent zu sein ...“

Der Vorteil dieser Notation in C / C ++ war es einfacher zu machen, um zu sehen, was ein Symbol der Typ war ohne Suche nach der Erklärung zu gehen. Diese Stile erschien vor der Ankunft von Intellisense und „Gehe zu Definition“ - wir mussten oft auf Gänsejagd gehen auf der Suche nach der Erklärung in wer weiß wie viele Header-Dateien. Auf einem großes Projekt dies eine erhebliche Belästigung sein könnte, die schlimm genug war, als bei C-Quellcode suchen, aber noch schlimmer, wenn Forensik mit Mischbestückung + Quellcode und einen rohen Call-Stack zu tun.

Wenn Sie mit diesen Realitäten konfrontiert, m_ verwendet und alle anderen ungarischen Regeln beginnt ein Gefühl auch bei den Wartungsaufwand zu machen, weil, wie viel Zeit es nur in Aufsuchen eines Symbols Art retten würde, wenn sie bei unbekannten Code suchen. Jetzt haben wir natürlich Intellisense und „Gehe zu Definition“, so die Hauptzeit Motivation dieser Namenskonvention sparen, ist nicht mehr da. Ich glaube nicht, dass es viel Sinn, das ist nicht mehr dabei, und ich versuche, im Allgemeinen mit den .NET-Bibliothek Richtlinien zu gehen, nur konsequent zu sein und möglicherweise ein wenig mehr Tool-Unterstützung zu gewinnen.

Ich bin sicher, dass ich dafür bekommen geflammt, aber so sei es.

Es ist Microsofts .NET-Bibliothek Richtlinien genannt, aber es ist wirklich Brad Abrams Ansichten ( Dokument hier ) - es gibt auch andere Ansichten mit triftigen Gründen.

Menschen neigen dazu, mit der Mehrheit der Ansicht zu gehen, anstatt für einen bestimmten Stil gute und solide Gründe haben.

Der wichtige Punkt ist, zu beurteilen, warum ein bestimmter Stil verwendet wird und warum es einen anderen Stil über bevorzugt wird - mit anderen Worten, haben einen Grund für die Wahl eines Stils nicht nur, weil jeder sagt es das, was zu tun ist -. Für sich selbst denken

Der wesentliche Grund für die nicht im alten Stil ungarischen mit der Verwendung von Abkürzungen wurde, die für jedes Team und schwierig war anders zu lernen -. Dies leicht durch nicht Abkürzen gelöst

Da die verfügbaren Entwicklungstools ändern Sie den Stil sollte sich ändern, was am meisten Sinn macht -. Aber einen soliden Grund für jeden Arteinzelteil haben

Im Folgenden sind meine Artrichtlinien mit meine Gründe - ich immer nach Wegen suchen, meinen Stil zu verbessern zuverlässiger und einfacher zu erstellen Code zu pflegen

Variable Namenskonvention

Wir haben alle unsere Sicht auf variable Namenskonventionen. Es gibt viele verschiedene Stile, die leicht zu pflegende Qualität Code produzieren helfen - jeder Stil, der die grundlegenden wesentlichen Informationen über eine Variable in Ordnung sind unterstützt. Die Kriterien für eine bestimmte Namenskonvention sollte sein, dass es in der Herstellung von Code hilft, die zuverlässig und leicht zu pflegende ist. Kriterien, die nicht verwendet werden sollen, sind: Es ist hässlich Microsoft (das heißt Brad Abrams) sagt, dass Stil nicht verwenden - Microsoft lässt sich nicht immer die zuverlässigste Code an den Bugs in Expression Blend anschauen. Es ist sehr wichtig, wenn der Code zu lesen, die ein Variablenname sofort drei wesentliche Fakten über die Variable vermitteln soll: es ist Anwendungsbereich es ist Art ein klar zu verstehen, was es für verwendet wird, Scope: Microsoft empfiehlt, ganz auf IntelliSense angewiesen zu sein. IntelliSense ist genial; aber tut man einfach nicht die Maus über jede Variable, um zu sehen, es ist Art und Umfang. eine Variable Unter der Annahme ist in einem Umfang, dass es nicht erhebliche Fehler verursachen. Wenn beispielsweise eine Referenzvariable wird als Parameter übergeben, und es wird im lokalen Bereich verändert, der nach der Methode zurück bleiben ändern, die möglicherweise nicht erwünscht ist. Wenn ein Feld oder eine statische Variable wird in lokalem Bereich geändert, aber man glaubt, dass es sich um ein lokales Variable unerwartetes Verhalten führen kann. Daher ist es äußerst wichtig in der Lage zu sein, nur mit einer variablen aussieht (nicht die Maus über) und sofort weiß, dass es Spielraum.

In der folgenden Art zur Anzeige Umfang wird vorgeschlagen; jedoch ist jeder Stil vollkommen in Ordnung, solange es klar und konsequent den Anwendungsbereich der Variable gibt: m_ Feldvariable p_ Parameter auf eine Methode übergeben S_ statische Variable lokale Variable Typ: Schwere Fehler kann auftreten, wenn man sie arbeiten mit einem bestimmten Typ glaubt, wenn sie mit einer anderen Art tatsächlich arbeiten - wieder, wir tun einfach Maus nicht über je Variable ihren Typ zu bestimmen, gehen wir davon nur, dass wir wissen, was seine Art und das ist, wie Fehler erzeugt werden.

Abkürzungen: Abkürzungen sind böse, weil sie verschiedene Dinge für verschiedene Entwickler bedeuten kann. Ein Entwickler kann denken, ein führender kleines „s“ bedeutet, String, während ein anderer vielleicht denken, es Signed Integer bedeutet. Abkürzungen sind ein Zeichen für faul Codierung - nehmen Sie ein wenig mehr Zeit und den vollständigen Namen klar in den Entwickler machen eingeben, um den Code zu halten hat. Zum Beispiel ist der Unterschied zwischen „str“ und „string“ nur drei Zeichen - es braucht nicht viel mehr zu tun, um Code einfachaufrecht zu erhalten.

Gemeinsame und klare Abkürzungen für integrierte Datentypen nur akzeptabel, sondern muss innerhalb des Teams standardisiert werden.

Selbst Dokumentieren Code: eine klare Beschreibung zu einem Variablennamen Hinzufügen macht es sehr einfach für andere Entwickler den Code zu lesen und zu verstehen - machen den Namen so verständlich, dass der Teammanager lesen und den Code verstehen, ohne ein Entwickler zu sein <. / p>

Reihenfolge der Variablenname Teile: Die empfohlene Reihenfolge ist Spielraum-Typ-Beschreibung, weil: IntelliSense werden alle ähnlichen Bereichen Gruppe und innerhalb der einzelnen Rahmen IntelliSense werden Gruppe alle ähnliche Typen, die Lookups leicht macht - versuchen, eine Variable, die den anderen Weg zu finden, Es macht es sehr einfach, den Umfang zu sehen und zu verstehen und zu sehen, und die Art zu verstehen Es ist ein ziemlich gemeinsamer Stil und leicht zu verstehen Es wird passieren FxCop

Beispiele: Hier sind ein paar Beispiele: m_stringCustomerName p_stringCustomerDatabaseConnectionString intNumberOfCustomerRecords oder iNumberOfCustomerRecords oder integerNumberOfCustomerRecords Diese einfachen Regeln erheblich Code verbessern die Zuverlässigkeit und Wartbarkeit.

Kontrollstruktur Einzellinie Statements Alle Kontrollstrukturen (if, while, für usw.) einzelne Zeilen Aussagen sollten immer mit Klammern eingewickelt werden, da es sehr einfach ist, eine neue Anweisung hinzufügen nicht ahnend, dass eine bestimmte Aussage zu einer Steuerstruktur gehört, die die Code-Logik brechen werden ohne jeder kompilieren Zeitfehler zu erzeugen.

Method Ausnahme Wrapping Alle Methoden sollten mit einem äußeren try-catch die Falle, bieten einen Ort, sich zu erholen, zu identifizieren, zu lokalisieren, sich einzuloggen, und eine Entscheidung treffen zu werfen oder nicht gewickelt werden. Es ist die unerwartete Ausnahme, dass unsere Anwendungen zum Absturz bringen - durch jede Methode Einwickeln alle nicht behandelten Ausnahmen Trapping Wir garantieren Ihnen zu identifizieren und alle Ausnahmen Anmeldung und wir verhindern, dass unsere Anwendung jemals abstürzt. Es dauert ein wenig mehr Arbeit, aber die Ergebnisse sind die Mühe wert.

Einrückungen Einrückungen ist kein großes Problem; jedoch vier Räume und nicht verwendet Registerkarten vorgeschlagen. Wenn der Code gedruckt ist, der erste Drucker Lasche in der Regel standardmäßig 8 Leerzeichen. Verschiedene Entwickler neigen dazu, verschiedene Register Größen zu verwenden. Microsofts Code ist in der Regel 4 Raum eingerückt so, wenn man alle Microsoft-Code verwendet und andere Verwendungen als 4 Leerzeichen, dann wird der Code müssen neu formatiert werden. Vier Räume macht es einfach und konsistent sind.

Wenn Sie nicht unter einer bestimmten Richtlinie Kodierung, sollten Sie Ihre tatsächliche m_ Notation halten verwenden und es ändern, wenn die Projektrichtlinien Codierung so sagen.

Seien Sie funktional.

Verwenden Sie keine globalen Variablen.
Verwenden Sie keine statische Variablen.
Verwenden Sie keine Membervariablen.

Wenn Sie wirklich haben, aber nur, wenn Sie wirklich müssen, ein verwenden und nur eine Variable Ihre Anwendung / Umgebung zugreifen können.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow