Welche Best Practices gelten für die Instanziierung/Initialisierung von Privatmitgliedern?

Question

Mögliche Duplizieren:
C# member variable initialization; best practice?

Gibt es einen Nutzen für diese:

public class RemotingEngine 
{ 
    uint m_currentValueId; 
    object m_lock; 

    public RemotingEngine() 
    { 
     m_currentValueId = 0; 
     m_lock = new object(); 
    } 

gegen diese:

public class RemotingEngine 
{ 
    uint m_currentValueId = 0; 
    object m_lock = new object(); 

Ich habe die zweite vermieden nur weil es sich anfühlt verflucht '. Es ist offensichtlich weniger tippen, so dass es für mich ansprechend ist.

Answer 1

es einen Unterschied in einer Vererbungs Situation machen kann.Siehe diesen Link auf das Objekt Initialisierungsreihenfolge:
http://www.csharp411.com/c-object-initialization/

1. Abgeleitet statische Felder
2. Abgeleitet statischen Konstruktor
3. Abgeleitet Instanz
4. Basis statische Felder
5. Basis statischer Konstruktor
6. Basisinstanzfelder Felder
7. Basisinstanzkonstruktor
8. Abgeleitet Instanzkonstruktors

Also, wenn dies eine abgeleitete Klasse, Objekt die gesamte Basis zwischen wenn der abgeleiteten Feld initialisiert wird initialisiert und wenn der Konstruktor ausgeführt wird.

Answer 2

Sie sind identisch, was die IL betrifft.

Der Compiler stellt sich dies:

class Foo 
{ 
    int bar = 1; 
} 

in diese:

class Foo 
{ 
    int bar; 

    public Foo() 
    { 
     this.bar = 1; 
    } 
} 

Auch wenn Sie einen Konstruktor sich wie folgt hinzu:

class Foo 
{ 
    int bar = 1; 

    public Foo(int bar) 
    { 
     this.bar = bar; 
    } 
} 

Der Compiler es in diese verwandelt:

class Foo 
{ 
    int bar; 

    public Foo(int bar) 
    { 
     this.bar = 1; 
     this.bar = bar; 
    } 
} 

Answer 3

Es gibt nicht viel Unterschied, ich würde mit dem ersten bleiben, weil es besser lesbar ist. Normalerweise sind Variablen am Anfang der Klasse definiert, und ich kann dorthin gehen und ihre Standardwerte auschecken, anstatt einen Konstruktor aufzuspüren und zu sehen, ob er gesetzt ist. Soweit es den Compiler betrifft, gibt es keinen Unterschied, es sei denn, Sie haben mehrere Konstruktoren.

Answer 4

Ich benutze immer die erste aus diesem Grund: Es ist die Verantwortung des Konstruktors Variablen zu initialisieren. Verschiedene Konstruktoren können Variablen unterschiedlich initialisieren. Also ja, du solltest dich schmutzig fühlen, wenn du es auf die zweite Art tust =).

Answer 5

Für die int, müssen Sie es nicht überhaupt, sind Eigenarten() auf Standard initialisiert - die, für die int ist 0.

Was Objekt, dann ist es eine Frage des Geschmacks imo. Ich bevorzuge das ehemalige. Wenn jemand meinen Konstruktor überschreibt, erwarte ich, dass er base() aufruft, um ihn in einem richtigen Zustand aufzubauen.

Answer 6

wollen Sie Instanziierung gegeben außerhalb des Anwendungsbereichs der Konstruktor zu vermeiden, dass es Absicht zeigt, und vor allem, wenn Sie Konstrukteurs zwingende haben Sie ein bisschen mehr Flexibilität

Answer 7

Ich bevorzuge die zweite und in einigen Fällen hängt es von Ihren Kodierungsstandards ab. Aber betrachten Sie die Abarbeitungsreihenfolge:

Zielklasse Feldinitialisierung -> Basisklasse Feldinitialisierung -> Basisklassenkonstruktor -> Ziel Klassenkonstruktors

wenn die Basisklasse oder Zielklasse eine Ausnahme zu schaffen, das Objekt und Die Felder sind vorinitialisiert, sie haben einen Wert bei der Finalisierung und können einige unerwartete Probleme verursachen.

Siehe auch diesen Blog von Bill Simser Best Practices and Member Initialization in C#

Answer 8

ich eine andere Perspektive auf diesem. Ich denke, Sie sollten zu Eigenschaften abstrahieren und sie im Konstruktor setzen. Die Verwendung von automatischen Eigenschaften würde die Frage grundsätzlich eliminieren, da Sie sie nicht initialisieren können (zu etwas anderem als dem Standard).

public class RemotingEngine { 
    private uint CurrentValueID { get; set; } 
    private object Lock { get; set; } 

    public RemotingEngine() 
    { 
     this.CurrentValueID = 0; // not really necessary... 
     this.Lock = new object(); 
    } 
}