Warum definieren Sie den Getter vor dem Setter (Codierungskonvention)

Question

Ich schätze diese Frage ist ein wenig albern, so entschuldige ich mich im Voraus, wenn das Thema nicht oder nicht konstruktiv ist.

Warum ist es in C# Standardkonvention *, Eigenschaften mit dem Getter vor dem Setter zu definieren? Bei Eigenschaften mit beiden wird der Setter fast immer vor dem Getter verwendet, damit er in einem gültigen Zustand ist. Daher erscheint es mir etwas rückständig, dass wir den Getter zuerst definieren.

Außerdem würde der Setter normalerweise eine Validierungslogik haben, die der Getter nicht benötigt. Wäre es nicht klüger, diese Logik dem Getter vor Augen zu führen, um klarer zu machen, wie sich das Eigentum verhalten soll? Zum Beispiel:

public decimal Price 
{ 
    get { return _price; } 
    set 
    { 
     if(value < 0m) 
     { 
      throw new ArgumentOutOfRangeException(); 
     } 

     _price = value; 
     OnPropertyChanged("Price"); 
    } 
} 

der Code in dem Setter ist viel interessanter als Getter, sollte es nicht Vorrang hat und zuerst definiert werden?

* Ich weiß, dass es keine Regeln mit diesen Dingen gibt, aber praktisch jedes Beispiel, jemals Eigenschaften definiert den Getter vor dem Setter.

Answer 1

Weil es besser ist zu geben als zu empfangen.

Auf eine ernstere Anmerkung, ich rate, weil wer auch immer das Schnipsel (oder was auch immer es ist, das den Eigenschaftscode in VS autogen) unbewusst diese Reihenfolge wählte.

Dann, wie der Rest von uns sind nur Schafe zu diesem Pionier Schäfer, folgten wir ohne Frage.

Bis Sie.

Sie stellen unseren einst großen Hirten in Frage, Anarchie kann nur folgen. Verpflichte deinen Code und renne nach den Hügeln.

Answer 2

Der Getter ist in der Regel viel kürzer (in der Regel eine Zeile), so dass es am Anfang setzen ermöglicht es Ihnen, besser zur Übersicht, wie Sie dies bevorzugen werden:

if (condition) 
{ 
    // Short code 
} 
else 
{ 
    // Long code 
    // Long code 
    // Long code 
    // Long code 
    // Long code 
    // Long code 
    // Long code 
    // Long code 
    // Long code 
    // Long code 
    // Long code 
    // Long code 
    // Long code 
    // Long code 
    // Long code 
    // Long code 
    // Long code 
} 

statt dem:

if (!condition) 
{ 
    // Long code 
    // Long code 
    // Long code 
    // Long code 
    // Long code 
    // Long code 
    // Long code 
    // Long code 
    // Long code 
    // Long code 
    // Long code 
    // Long code 
    // Long code 
    // Long code 
    // Long code 
    // Long code 
    // Long code 
} 
else 
{ 
    // Short code 
} 

Und mehr als das - nur weil.

Answer 3

Die Reihenfolge der Getter und Setter sind völlig irrelevant, ich denke, der Grund für die Konvention ist Visual Studio Eigenschaft Snippet, die die Eigenschaften auf diese Weise generiert (Getter vor Setter). Nachdem ich dieses Snippet ein paar Mal benutzt habe, ist diese Reihenfolge für die meisten Programmierer (einschließlich mir selbst) zu einer ungeschriebenen, unbewussten Übung geworden. Das erklärt natürlich nicht, warum VS-Designer den Snippet auf diese Weise implementiert haben. Meine Meinung: Sie wissen es nicht, und sie kümmern sich nicht darum, oder vielleicht weil g früher im englischen Alphabet kommt als s. Wie auch immer, wer auf der Welt hat so viel Zeit sich zu kümmern?

Answer 4

Ich denke, das Wichtigste hier ist Konsistenz. Während in Ihrem Beispiel der Setter "interessanter" ist, glaube ich nicht, dass dies die meiste Zeit notwendigerweise der Fall ist. Einer der Gründe, warum Auto-Eigenschaften so nützlich sind, liegt in der Häufigkeit, mit der der get- und set-Code einfach von einem privaten Feld ohne weitere Verarbeitung gelesen/in dieses geschrieben wird. In diesem Fall ist keiner "interessanter".

In Ihren eigenen Projekten können Sie sie natürlich in beliebiger Reihenfolge setzen, und wenn Sie sich entscheiden, dass die Setter aufgrund von "Wichtigkeit" oder aus einem anderen Grund zuerst kommen sollten, können Sie das tun damit.Angesichts der weit verbreiteten Natur der Getter-Before-Setter-Konvention wäre es jedoch sinnvoll, wenn Sie Ihren Code teilen möchten, den Konventionen zu folgen, um sie in Zukunft lesen oder ändern zu können.