Welche aktuellen Best Practices werden in Bezug auf das Schlüsselwort "this" vor dem Feld und die Methoden in c # angesehen?


14

Sofern es nicht erforderlich ist, zwischen einer Variablen und einem Feld mit demselben Namen zu unterscheiden, stelle ich this.in C # niemals ein Feld oder einen Elementzugriff vor. Ich sehe dies nicht anders m_als das in C ++ übliche Präfix und denke, wenn Sie wirklich angeben müssen, dass es sich um ein Mitglied handelt, ist Ihre Klasse zu groß.

Es gibt jedoch eine Reihe von Leuten in meinem Büro, die überhaupt nicht einverstanden sind.

Was wird als aktuelle Best Practice angesehen this.?

EDIT: Zur Verdeutlichung benutze ich niemals m_und nur this.wenn unbedingt nötig.


Was m_soll das heißen?
FrustratedWithFormsDesigner

2
@Frustrated Dass die Variable ein Mitglied der Klasse ist.
Michael Todd

Entschuldigung, ich hatte die Annahme gemacht, dass niemand denken könnte, dass ich ungarische Notation benutze. Ich habe versucht zu sagen, dass ich this.fast so schlecht bin wie m_.
Andy Lowry

3
Alter, einfach StyleCop installieren und ausführen! Dies ist sicherlich auch ein Betrug einer SO-Frage.
Job

3
Es spielt keine Rolle, ob Sie mit Ihrem Team einverstanden sind oder nicht. In einem Team müssen Sie immer noch konsistent sein. Vor allem, wenn das Team größer wird, wird es anders, als im wilden Westen, und Sie wissen, was die Leute über Cowboy-Codierer sagen. ;-)
Chris

Antworten:


14

Gemäß den Framework-Gestaltungsrichtlinien gilt Folgendes , wenn auf öffentliche oder geschützte Felder Bezug genommen wird:

Verwenden Sie KEIN Präfix für Feldnamen.

Zum Beispiel m_ist ein Präfix.

Daher eignet sich die öffentliche Bekanntmachung eines Feldes für die Verwendung des thisSchlüsselworts, wie in MSDN erläutert

So qualifizieren Sie Mitglieder, die unter ähnlichen Namen ausgeblendet sind: Kopieren

public Employee(string name, string alias) 
{
   this.name = name;
   this.alias = alias;
}

Wenn Sie sich auf private Felder beziehen, können Sie das verwenden, m_wenn Sie möchten. Für öffentliche Bereiche empfehle ich jedoch, die Best Practices zu befolgen.

Persönlich mag ich keine Unterstriche in meinen Variablennamen. Ich versuche auch konsequent zu sein. Es this.name = name;ist also eine gute Faustregel, sowohl in öffentlichen als auch in privaten Szenarien zu arbeiten.


+1: Darauf habe ich in meiner Antwort Bezug genommen, aber Ihre Antwort ist viel aussagekräftiger.
Joel Etherton

1
Einverstanden - Ich habe mehrere Szenarien gesehen, in denen Sie eine Eigenschaft, ein Mitglied und eine lokale Variable mit demselben Namen haben. Die Eigenschaft ist Pascal (Großbuchstabe), sodass Sie zwei Variablen in Kamel-Schreibweise (erster Buchstabe unten) haben. Der einzige Weg, um zu unterscheiden, ist mit "dies". (empfohlen) oder ein Präfix (nicht empfohlen). Ich habe beides verwendet und in der Praxis erleichtert dieses Schlüsselwort das Verfolgen (IMO).
Mayo

1
Das Lustige an der Framework-Empfehlung ist, dass die CLR-Quelle mit dem m_Präfix übersät ist. Ich denke, '_' ist ein gutes Präfix, da Sie sich nie um Stapelüberlaufprobleme aufgrund von Zuweisungsfehlern sorgen müssen
Chris S

@Chris S - Nach meiner Erfahrung ist Microsoft gut darin, einen "evolutionären Code-Prozess" zu dokumentieren und aufrechtzuerhalten. Sie haben viele Praktiken angewandt, die heute als "schlechte Praktiken" gelten. Höchstwahrscheinlich, weil sie aus ihren Fehlern gelernt haben. Dies bedeutet nicht, dass sie zurückgegangen sind und vorhandenen Code geändert haben, da sich der Aufwand nicht immer lohnt. Befolgen Sie unbedingt die neuesten Richtlinien in neuem, nicht älterem Anwendungscode.
P.Brian.Mackey

11

In unserem Team haben wir den Standard der Verwendung des Qualifizierers this.oder des Me.Objektqualifizierers in größeren Klassen übernommen, damit Junior-Entwickler den genauen / unmittelbaren Gültigkeitsbereich einer Variablen durch einfaches Betrachten leichter erkennen können.

In Bezug auf den Code ist dies eine völlig unnötige Beeinträchtigung, aber es blockiert nichts, da es am Ende ohnehin den gleichen exakten MISL-Code generiert. Wir haben es nur übernommen, weil es ein unmittelbares Problem ansprach, das wir bei einigen Junioren entdeckt haben. Darüber hinaus sehe ich es nicht als hilfreich an, es aufzunehmen.


Toller Punkt über die Junior-Codierer.
Patrick Hughes

2
Sollten Ihre Klassen nicht kleiner sein? Oder ist das ein altes Problem?
Tjaart

@Tjaart: Klassen sind so groß oder so klein, wie sie sein müssen. Selbst in einer kleinen Klasse kann es leicht sein, den Gültigkeitsbereich einer Variablen so zu vergessen, wie er auf dem Bildschirm angezeigt wird.
Joel Etherton

1
Warum haben Ihre Junioren Probleme bei JoelEtherton? Python-Junioren haben ein umgekehrtes Problem, bei dem sie vergessen, sich selbst hinzuzufügen. um auf private Variablen zuzugreifen. Vergessen die Junioren nicht einfach den Kongress und bringen ihn durcheinander?
Tjaart

1
@Tjaart: Manchmal. Sie haben Probleme, weil sie Junioren sind und manchmal einfach nicht aufpassen oder noch kein geübtes Auge haben. Wir verwendeten diese Technik eher als Wegweiser als als Standard oder Konvention. Seit diesem Beitrag ist es hier tatsächlich in Vergessenheit geraten, da sich alle unsere Junioren an die Umwelt gewöhnt haben. Ich stelle mir vor, wenn wir neue Junioren einstellen (es ist unwahrscheinlich, dass wir es bald tun), könnte es wieder kommen.
Joel Etherton

10

StyleCop erzwingt die Verwendung von this.Also, wenn Sie dies als Best Practice betrachten (was ich auch tue), dann ist die Verwendung von this.Best Practice.

Der von Ihnen gewählte Stil hängt von Ihnen und Ihren eigenen Codierungsstandards ab. "Am besten" ist das, was Sie als "am besten" definieren. Sei einfach konsequent. Eine inkonsistente Verwendung führt nur zu Verwirrung.

Mein Argument ist, dass bei Verwendung this.von die Tatsache aufgerufen wird , dass Sie auf Instanzeigenschaften verweisen, sodass beispielsweise hervorgehoben werden kann, dass Sie sie mutieren (sofern vorhanden this.x = ...). Dies ist möglicherweise etwas, das Sie wissen möchten. Es wird auch die Tatsache hervorgehoben, dass this.Ihre Methode zu jedem Zeitpunkt, zu dem Sie sie sehen , niemals statisch sein kann. Wenn Sie eine Konvention wie m_diese verwenden, ist dies ebenfalls möglich. Wenn Sie jedoch m_eine statische Methode erstellen oder eine Methode neu definieren, um den Wert von außerhalb der Klasse zu übergeben, müssen Sie daran denken, den Namen zu ändern, wenn Sie eine solche verwenden thisDann zwingt der Compiler Sie, die Änderung vorzunehmen.

Einfach ausgedrückt thisist die Verwendung einfacher, da der Code nicht kompiliert werden kann, wenn Sie m_ihn manuell verwenden und die Tools nicht nutzen.


9
Und Resharper wird vorschlagen, das "this" zu entfernen. Ihr Kilometerstand kann variieren.
Carra

Wie? Resharper hat mir das nie vorgeschlagen. Vielleicht liegt es daran, dass ich das StyleCop-Plugin habe?
Jesse C. Slicer

1
Wenn StyleCop installiert ist, wird diese Option in R # deaktiviert.
Steve

5

Das Schöne an der Verwendung m_ist, dass Sie, sobald Sie den kleinen mIntellisense eingeben, eine Liste aller Ihrer privaten Variablen erhalten. Ich persönlich halte dies für ein Plus. Aus ähnlichen Gründen würde ich mich auch s_für private Statik und c_private Konstanten entscheiden. Es ist eine ungarische Schreibweise, aber in dem Sinne, dass sie dem Variablennamen eine nützliche Bedeutung hinzufügt, damit jeder andere Programmierer Dinge über den Namen erzählen kann, die möglicherweise nicht ganz offensichtlich sind.

Ich bin ganz sicher nicht damit einverstanden, keine Möglichkeit zu haben, zwischen Mitgliedsvariablen und Nichtmitgliedervariablen zu unterscheiden, weil sie unterschiedlich sind, und wenn ich Code lese, bei dem die Leute nichts tun, um zu unterscheiden, ist es wirklich schwerer zu lesen. Verwenden this.fühlt sich einfach an wie mehr Kesselplatte als nötig. Aber wirklich ist es persönlicher Geschmack, wenn Sie eine Zeit lang in eine Richtung codieren, dann denken Sie am Ende, dass dies richtig und alles andere falsch ist. Das einzige, was wirklich zählt, wenn das Schema vernünftig ist, ist, dass jeder im Team konsistent ist.


4
Oder tippen Sie this.und lassen Sie sich von Intellisense helfen.
Steve

1
@Steve Haigh: Du verpasst den Punkt, er sagt, er kann alle Arten von Mitgliedern gruppieren, da die Liste alphabetisch sortiert ist, alle m_ zusammen erscheinen, alle s_ zusammen usw.
gbjbaanb

2
using this.gibt Ihnen alles in der Klasse, ohne auf veraltete Namenskonventionen zurückgreifen zu müssen. Ich verstehe den Sinn verschiedener Buchstaben, ich glaube einfach nicht, dass sie notwendig sind. Wenn Sie so viele Eigenschaften, Konstanten usw. in einer Klasse haben, dass Sie diese Konvention benötigen, ist Ihr Design ziemlich kaputt.
Steve

2
@Steve Haigh: Das ist großartig in der theoretischen Welt, in der jeder im Team ein großartiger Programmierer ist und sie alle ihre Klassen in kleine Stücke aufteilen und gut überarbeiten und Zeit haben, über Design usw. nachzudenken. Meiner Erfahrung nach tut dies das Leben nicht ganz qhite so aus. Aber ich stimme zu, dass Sie in einer idealen Welt wahrscheinlich Recht haben.

@Steve: Durch Tippen erhalte m_ich eine Liste aller Mitgliedsvariablen. Durch Tippen this.erhalte ich eine Liste der Mitgliedsvariablen und Mitgliedsfunktionen.
Sean

4

thisist explizit. Es ist ein optisches Zeichen, das Sie nicht verfehlen können.

Ich bevorzuge fast immer expliziten Code gegenüber impliziten Code. Deshalb benutze ich thishäufig. Ich halte es für eine bewährte Methode.


4

Ich benutze immer "das". Die Argumentation basiert auf zwei einfachen Fakten:

  • Das Lesen von Code ist schwieriger als das Schreiben von Code.
  • Sie lesen Code häufiger als Sie Code schreiben.

Die Verwendung von "this" macht es für jeden, der liest (dh nicht nur für den Autor, sondern möglicherweise auch für den Autor innerhalb von 6 Monaten, nachdem Einzelheiten der Implementierung vollständig vergessen wurden), deutlich, dass dies ein Klassenmitglied ist. Ich rede hier. "m_" und dergleichen ist nur eine Konvention, und wie jede andere Konvention kann sie missbraucht (oder überhaupt nicht verwendet) werden - es gibt weder zur Kompilierungszeit noch zur Laufzeit etwas, das "m _" / etc erzwingen könnte. "this" ist stärker: Sie können "m_" in eine lokale Variable einfügen, und der Compiler beschwert sich nicht. das kann man mit "this" nicht machen.

Wenn überhaupt, finde ich es bedauerlich, dass die Verwendung von "this" in Sprachspezifikationen nicht obligatorisch ist.

Als netter Bonus können Sie beim Debuggen über das "Dies" fahren (oder eine Uhr hinzufügen) und auch alle anderen Klassenmitglieder überprüfen - wertvolle Informationen.


3

Das thisSchlüsselwort wird insbesondere zur Unterscheidung von 2 vorhandenen Variablen verwendet, insbesondere wenn Sie einen Konstruktor oder eine Methode mit einer Variablen mit demselben Namen haben, die jedoch denselben Typ haben kann.

Beispiel:

public class Example {

    string reason;
    string cause;

    Example (string reason, string cause) {
        this.reason = reason;
        this.cause = cause;
    }

    //<Setter> if you want to explicitly write your onw
    public void setReason(stirng reason) {
        this.reason = reason;
    }
}

Dies (zB this.reason = reason) weist den Variablen in der Klasse grundsätzlich den Wert aus den Parametern zu. thisNimmt im Grunde die Klasse reasonaus dem Parameterblock.


2

Darüber habe ich mich auch schon länger gewundert. Nachdem ich einige umfangreiche Codierungen in Javascript vorgenommen hatte, habe ich mich dabei erwischt, this.häufiger in meinem C # -Code zu verwenden (vorher habe ich ihn fast ausschließlich in Konstruktoren oder ähnlichen Methoden verwendet, um Mehrdeutigkeiten zu vermeiden). Es macht den Code ein bisschen klarer, ohne dass zusätzliche Anstrengungen erforderlich sind. Außerdem werden die Namen Ihrer Klassenmitglieder nicht durch Präfixe verfälscht, und Sie können bei klarem Kontext oder in besonders komplexen Anweisungen immer noch auf die Verwendung der Elemente 'the short way' zurückgreifen. Ich füge nur hinzu this., wenn ich eine längere Methode, eine längere Argumentliste oder viele lokale Variablen deklariert habe und ich denke, der Code könnte von zusätzlicher Klarheit profitieren, auch wenn er erzwungen wird.

Aber ich persönlich hasse den m_Präfix-Stil absolut , nicht so sehr aufgrund von Ungarisch, sondern weil Unterstrichen ein mühsamer Tipp ist;) Also halte ich es nicht für eine Alternative. Ich gebe zu, es hat seine Stärken, wenn es um Intellisense geht. Sie können jedoch auch argumentieren, dass Ihre Klasse zu groß ist, wenn Sie sich nicht an die ersten Buchstaben einer Mitgliedsvariablen erinnern können.


1

Ich überlege mir ein einzelnes Unterstrich-Präfix für die Teilnehmer. _someVar;

Warum? Sie wissen auf den ersten Blick, dass es sich um ein Mitglied handelt, nicht um eine Stapelvariable. Bequemlichkeit auf einen Blick. Und es dauert weniger Unordnung im Vergleich zu dem Schlüsselwort "this".


1

Die Verwendung von Dingen wie dem this.Präfix / Schlüsselwort, die weder notwendig sind noch das Ergebnis verändern, ist immer subjektiv. Ich denke jedoch, dass wir uns einig sein können, dass die meisten von uns Felder von lokalen Variablen unterscheiden möchten. Einige verwenden ein Unterstrich - Präfix (was ich hässlich finde und eine Art ungarische Notation), andere verwenden dasthis. Schlüsselwort. Ich bin einer der letzteren. Es geht nur um Lesbarkeit und Verständlichkeit. Es macht mir nichts aus, ein bisschen mehr zu tippen, wenn es klarer oder lesbarer ist. Ich möchte Felder und Variablen im Handumdrehen unterscheiden.

Ich definiere immer Felder mit ähnlichen myFieldNamen und Parameternamen sowie lokale Variablennamen mit ähnlichen Namen myField. Keine Unterstriche, keine Präfixe. Ich verwende thisüberall dort, wo ich mich auf ein Feld beziehe. Auf diese Weise kann ich Felder von lokalen Variablen und Argumenten ohne Präfix unterscheiden. In einem solchen Fall ist natürlich das thisSchlüsselwort erforderlich:

public Person(string firstName)
{
    this.firstName = firstName;
}

Meine Eigenschaften sehen daher so aus (ja, ich habe das Feld immer mit der Eigenschaft versehen und nicht an einer anderen Stelle oben in meiner Datei):

private string firstName;
public string FirstName
{
    get { return this.firstName; }
}

Es liest sich gut: Geben Sie diesen Vornamen zurück .


-2

EDIT: Meine Antwort ist eindeutig keine Antwort. Also hier ist eine Bearbeitung. In den Codierungsrichtlinien von Microsoft heißt es:

2.6 Benennung

Verwenden Sie kein Präfix für Elementvariablen ( , m , s_ usw.). Wenn Sie zwischen lokalen und Mitgliedsvariablen> unterscheiden möchten, sollten Sie "this" in C # und "Me" in VB.NET verwenden.

Kann unter folgender Adresse gefunden werden: http://blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspx

Es scheint also, dass es zumindest bei MS keine klare Richtlinie gibt, obwohl eine andere Antwort besagt, dass StyleCop es zu einer Richtlinie macht. Es gibt keine Autorität in diesen Dingen, daher würde ich vorschlagen, dass Sie sich selbst entscheiden oder in diesem Fall Ihrem Team nachgeben. Es ist keine so große Sache.

Meine ursprüngliche Antwort stimme ich Ihnen persönlich zu, aber vielleicht wäre ein Leseverständnistest, bei dem die beiden Methoden gegeneinander getestet werden, wertvoll. Ansonsten sind diese Stilsachen nur schlammig.

Meine Salve lautet: Meiner Meinung nach verkomplizieren Leute unnötigerweise ihren Codestil, und wenn sie darauf hinweisen müssen, dass etwas eine Klassenvariable ist, kann der Code einige andere schwerwiegende strukturelle Probleme aufweisen, wie die uralte Rezeptmethode von Platzieren Sie private Variablen an der Spitze der Klasse, sodass Sie ständig nach oben und unten scrollen müssen.

Dies scheint mir eine dieser Konventionen zu sein, bei denen "Was ist das?" Es sollte bevorzugt werden, dass die Kürze explizit ist. Diese Lektion wird häufig von dynamischen Sprachen wiederholt. Wir brauchen nicht den ganzen Flaum!


1
-1. Anstatt die Frage zu beantworten, geben Sie nur Ihre Meinung ab, die nicht die besten Praktiken widerspiegelt.
Arseni Mourzenko

Also nach Stylecop Gebrauch davon. ist best practice @MainMa. Ich stimme überhaupt nicht zu. Ich werde die Antwort bearbeiten, um das zu vermerken.
Tjaart

@MainMa ist das jetzt besser? Viele andere Antworten geben nur eine Meinung ab, werden aber nicht abgelehnt. Was sind die Best Practices und wo sind sie zu finden?
Tjaart

-3

Dies. kann oft zu unerwünschten Geräuschen führen.

Hier ist meine Lösung:

  • Parameternamen
  • local_variables
  • ANY_CONSTANT
  • _Private_Mitglieder
  • NonPrivateProperties
  • _NonPrivateProperty // Backer
  • Privatbesitz
  • _privateProperty // Unterstützer

2
Dies steht im Widerspruch zum üblichen .Net-Stil. kamel und pascal gehäuse den ganzen weg durch. Ihre Methode ist ziemlich inkonsistent. Es ist auch eine ziemlich alte Regel, Konstanten zu kapitulieren, und sie wird in der allgemeinen .Net-Community nicht verwendet.
Tjaart

Ich hoffe, Sie
fügen

Ich verstehe nicht, wie Sie das hinzufügen wollen. wird Lärm machen, aber all dieser Unsinn tut es nicht
Travis Weston
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.