Zwei C # Namenskonventionen: Was denken Sie? [geschlossen]

https://stackoverflow.com/questions/823294

05-07-2019
|

Frage

Ich habe zwei spezifische C # Kodierungskonventionen Ich habe mit gemischten Gefühlen zu üben. Ich wäre neugierig zu hören, was die Leute denken. Sie sind:

# 1. Nennen Sie Instanzen nach der Klasse, es ist eine Instanz, camelcase

# 2: "Zu den Eigenschaftsnamen"

Hier ist die Begründung:

# 1. Nennen Sie Instanzen nach der Klasse, es ist eine Instanz, camelcase

Ich benutze dies als Standard-Einstellung für die Namenskonvention. Natürlich gibt es Ausnahmen. Aber verwendet konsequent es dramatisch Code Klarheit und Wartbarkeit verbessert. Der Code sieht wie folgt aus:

var dataConnection = new DataConnection();
//not: var dataConn, dbConn, sqlConn, myDbPickOfTheDay etc.

FileInfo fileInfo = new FileInfo();

Timer timer = new Timer(); 

//etc.

ich an dem Punkt bin, wo Code wie folgt mir körperliche Schmerzen verursacht:

DataConnection dbConn = new DataConnection();

Ich kann nicht genug betonen, wie diese Konvention den Schmerz und die Wut des Variablennamen Spiels weggenommen hat.

Diese Konvention in scharfem Kontrast zu nennen Dinge zu versuchen, in einer Weise, die angeben, versuchen, was die Instanz tut, was zu versuchen, beläuft sich auf kreative Weise die Business Case in Code einbetten. Code hat einen Weg zu dem Punkt Refactoring immer, wo diese ursprünglichen Namen bestenfalls irreführend.

Für mich ist diese Konvention Gold. Es verhindert auch die schreckliche Praxis leicht Variablennamen für die gleiche Sache gezwickt.

Ein Beispiel für diese Konvention in der Praxis ist:

class Person { ...
   public string FirstName { get; set; }

//and then
var person = new Person();
person.FirstName = firstName; //where firstName comes from somewhere else.

Sehr leicht zu lesen. Sehr langweilig. Langweilig ist gut, wenn es darum geht, Code beibehalten wird.

Jedoch , diese Konvention führt mich zu # 2:

# 2 "Passende Eigenschaftsnamen" (mangels eines besseren Titel)

Hier ist ein Beispiel:

public class ShoppingCart { ..
  private Item item;
  public Item Item {  //<---- ?
  get { return this.item; } ...

Der Compiler ist vollkommen zufrieden mit diesem. Und in der Tat macht es eine sehr schöne Oberfläche:

//notice how tempting it is to just say "ShoppingCart cart ... "
ShoppingCart shoppingCart = new ShoppingCart();  
shoppingCart.Item = item;

Nun, die Alternative ist, kreativ zu sein - Sie müssen tatsächlich zwei gute Variablennamen für Artikel zum trommeln: der öffentliche Eigenschaft Namen und die privaten Variable Namen.

Wie oft haben Sie gesehen haben, und wollen einfach nur sofort in Rente gehen?

 public class ShoppingCart { ..
      private Item cartItem;
      public Item ShoppingCartItem { 
      get { return this.cartItem; } ..
  ///....
  ShoppingCart userShoppingCart = new ShoppingCart();
  userShoppingCart.ShoppingCartItem = userSelection;

Ich fühle mich stark genug über Konvention # 1, die ich denke, dass ich mit # 2 leben kann.

Was denken Sie?

Lösung

, falls Sie waren nicht bewusst, und wenn Sie sich interessieren, C # hat bereits einen Benennungsstandard

http://msdn.microsoft.com/en -US / library / xzf533w0 (VS.71) aspx

Auch bei Ihren Konventionen wieder auf der Suche ... hier einige weitere Vorschläge.

fileinfo sieht ziemlich neben Fileinfo, aber es hat keine andere Bedeutung als es die Art, die ich schnell durch Maus über die Art oder in Intellisense zu bekommen. Ich würde vorschlagen, Ihre Variablen mit Bedeutung und einem bestimmten Kontext, falls verfügbar zu benennen. remoteWebServerLog, localWebServerLog oder sogar localWebServerLogFileInfo, wenn Sie mögen die Art im Namen.

Wenn ich einen Rat von immer wieder kommen, um Code von Hand aus können Sie 6+ mos später geschrieben habe. Sie werden Ihren Kopf versuchen, herauszufinden, und die Spur zu kommen, was zum Teufel alle dbconn und fileinfo die sind kratzen. Welche Datei? Was db? Viele Anwendungen haben mehrere dbs, ist dies dbconn zum OrdersDB oder ShoppingCartDB?
Klasse Namensgebung sollte beschreibend sein. Wwould ShoppingCartItem Artikel bevorzugen. Wenn jede List-Box, Drop-Down genannt etc ihre Sammlung Artikel „Item“ Sie mit einer Menge von Namensräumen zu kollidieren würden und würde Wurf Ihren Code mit MyNameSpace.ShoppingCart.Item gezwungen werden.

Having said, dass alle ... auch nach Jahren der Codierung ich vermasseln noch und folgt nicht den Regeln 100% der Zeit. Ich könnte sogar Fileinfo fi verwendet habe = ... aber das ist, warum ich meinen ReSharper lieben „Refactor-> Umbenennen“ Befehl und ich verwende es oft.

Andere Tipps

Convention # 1 kann verwirrend sein. Wenn Sie in der gleichen method-- zwei FileInfo Objekte haben waren sagen, eine Quelle und ein Target-- Sie bräuchten aus der Konvention, um abweichen, die beide zu nennen.

Variablennamen sollten die Absicht seiner Verwendung für den flüchtigen Beobachter, um anzuzeigen, sein mnemonic--.

Vielleicht möchten Sie am glücklichsten mit einer Kombination der beiden Konventionen ... wie sourceFileInfo und targetFileInfo sein, pro diesem Beispiel.

Natürlich können Sie nicht jedes System.String in Ihrem Projekt eines Namen string *, , aber für Dinge, die Sie nicht viel nutzen, esp. Dinge, die Sie nur eine, und deren Funktion benötigen in Ihrem Code ist aus dem Namen der Hand, diese Namenskonventionen durchaus akzeptabel sind.

Sie sind, was ich tun, sowieso.

ich mit einem bestimmten Namen für, sagen wir, der Timer-Objekt gehen würde. Was ist es ein Timer für? Aber ich würde auf jeden Fall eine Dataconnection-Datenverbindung nennen.

* Auch wenn "string" war kein Schlüsselwort ...

ich 1 die ganze Zeit und finde es sehr gut lesbar. Ich bin auf dem Zaun mit 2. Ich kann es in bestimmten Situationen verwirrend finden, vor allem, weil es schwer ist, die Art der Immobilie aufgrund der Kennungen identisch sind.

zu unterscheiden

Ich würde normalerweise Konvention # 1, obwohl für lange Klassennamen folgt Ich neige dazu, nur die Initialen der Klasse zu verwenden. Wenn ich mehr als ein Objekt des gleichen Typs beziehen mich dann würde ich den Typnamen mit einem Namen Pre-pend anzeigt, welches es ist oder was es verwendet für.

ich ziemlich oft benutzen Konvention # 2, wenn es Sinn macht. Es gibt nichts Schlimmeres, als so etwas wie das Beispiel mit Ihnen cart.ShopingCartItem aufgeführt, die Tatsache, dass es eine Eigenschaft von ShoppingCart ist, macht, dass ein Teil des Eigenschaftsnamen völlig überflüssig. Allerdings würde ich ganz Namen wahrscheinlich die Klasse ShoppingCartItem und die Eigenschaft Item. Der Artikel ist ein wenig zu allgemein ein Name während ShoppingCartItem Ihnen sagt, welche Art von Element, das Sie arbeiten.

Ich folge Konvention 1 die ganze Zeit. Obwohl ich ein zusätzliches Qualifikationsspiel füge, wenn es von Seite zwei Objekte Seite ist.

Aber gesagt hat, dass, so dass diese Konvention zwingend problematisch sein kann:

In einem bestimmten Kontext cart kann ein gut genug, um Namen für ein ShoppingCart Objekt sein (wenn zum Beispiel kein anderes ist ‚Warenkorb‘ in der gleichen Funktion zu verwechseln mit).
Manchmal ist die Konvention kann völlig unklar ist der Zweck des angegebenen Objekts. Zum Beispiel Window scoreBoard = new Window() sagt, dass wir ein Objekt, das in der Tat ein Fenster ist, sondern als Anzeigetafel verwendet wird. Sehr ausdrucksvoll. Aber folgende Konvention 1 müssten Sie Window window = new Window() schreiben, die völlig versteckt die Absicht hinter diesem Fenster.

Also ich würde sagen, Gebrauch diese Name Idee überall, außer wenn es behindert Bedeutung oder erscheint unangemessen anspruchsvoll.

Über Konvention 2, ich voll und ganz zustimmen. Keeping Eigenschaftsnamen prägnant und lassen den Objektnamen, die volle Bedeutung ihres Aufrufs vervollständigen ist eine elegante Sache. Es arbeitet perfekt mit gut benannten Objekten. So gibt es wenig Grund, schüchtern zu sein, es zu benutzen.

Ich mag nicht stark den Begriff in ihrem Umfang mehrere Kennungen, die nur von Groß- / Kleinschreibung in ihrer Verwendung unterscheiden; wenn ich meine druthers hatte, Code, der eine Kennung verwendet, erforderlich wäre, um die gleiche Kombination von Groß- / Kleinbuchstaben als Erklärung zu verwenden, aber Code würde weder erlaubt werden zwei Kennungen im gleichen Umfang zu erklären, die nur von Fall unterscheiden, noch Zugang jede Kennung, die würden - ausgenommen Fall - einen Identifikator in einem inneren Umfang entsprechen. Obwohl keine Sprache, die ich kenne (schon gar nicht VB noch C #) ein solche Regelung erzwingt, in Übereinstimmung geschriebener Code mit solchen Regeln frei tragbare zwischen Groß- und Kleinschreibung nicht-case-sensitiven Sprachen sein könnte Bezeichner umbenennen ohne.

Folglich Ich mag nicht das Muster # 2. CLS-Kompatibilität erfordert, dass alle Kennungen dieses Stils private oder internal Umfang eingeschränkt werden. Da sowohl vb.net und C # Namen erlauben mit Unterstrichen zu starten, wenn eine Eigenschaft Trait genannt wird, sehe ich keinen Grund trait über _trait zu begünstigen. Die Verwendung des letzteren Namens wäre eindeutig Fälle unterscheiden, wenn der Programmierer auf die Sicherung Variable schreiben wollte sich von denen, wo seine Finger rutschte auf der Shift-Taste.

Wie für Muster # 1, in Fällen, in denen der ganze Zweck eines Typs oder Verfahren um ein einzelnes eingekapselten Objekt von einem bestimmten Typ aufgelöst wird, ziehe ich es vor Präfix Felder mit my oder Parameter mit the. Selbst in Fällen, in denen der Compiler den gleichen Namen zum Beispiel Mitgliedern und Parametern verwendet werden sollten erlauben würde, indem verschiedene Präfixe vermeidet die Möglichkeit, versehentlich eine Verwendung, wo der andere benötigt wird.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow