[erledigt] Memberfunktion mit "this" versehen?

Hallo Forum!

Kann mir jemand sagen, warum stylecop von Microsoft meint, ich solle Memberfunktionen mit dem "this" prefix versehen?

Bei Membervariablen kann ich es ja verstehen, aber was könnte der der Aufruf von "anyFunction()" seien außer der Aufruf einer Memberfunktion? Wozu "this.anyFunction()" ?

damit man sieht, das es ein aufruf innerhalb der klasse selbst ist. das ist aber echt nur geschmackssache.
resharper z.b. meckert es per default an.

Vielleicht meint StyleCop, dass es mit this klarer wäre.
Ich finde das kann man machen, muss man aber nicht. 😁

ja, das ist eine umformulierung meiner aussage.....

damit man sieht, das es ein aufruf innerhalb der klasse selbst ist

won wo soll es denn sonst ein Aufruf sein?

lesbarkeit..... nichts anderes.

edit: wobei es mich z.b. mehr stört, da ich es nicht gewohnt bin. -> pure geschmackssache.

irgendwie weiß ich immer noch kein einziges argument dafür, dass "this" vor Memberfunktionsaufrufen die Lesbarkeit erhöhrt.

Hallo sowieso,

public class Foo {
  public Foo(string name) {
    this.name = name;
  }

  private string name;

  public string Name {
    get { return this.name; }
  }
}

Der Konstruktor würde ohne verwendung von this die übergebene Variable mit sich selbst beschreiben.

Hallo sowieso,

tut es in meinen Augen auch nicht. Ich verwende this nicht mal vor Feldern oder Properties. Vor Methoden ist es - wie du richtig sagst - erst recht witzlos.

Hallo frisch,

das übliche Beispiel, aber es geht hier um this vor Methoden.

herbivore

Hallo herbivore,

würde dann wohl eher nur wegen der Lebsarkeit verwendet...

Angenommen eine Methode ruft eine andere Methode innerhalb der Klasse und eine Methode der Basisklasse auf. Die Methoden haben die gleichen Namen, dann würde ich wahrscheinlich beide Aufrufe mit Prefixen versehen:

this.Foo();
base.Foo();

Ansonsten seh ich keinen zusätzlichen Grund für solche Vorgehensweisen.

ach stimmt, ich hab ja Basisklassen ganz vergessen 😉

Das ist wirklich ein Argument ja. Danke Euch!

Hallo frisch,

mal abgesehen davon, dass solche Situation extrem selten sein dürften, würde aber auch base reichen, um die Aufrufe zu unterscheiden, ohne dass man beim anderen this angibt.

herbivore

Wie gesagt:

würde dann wohl eher nur wegen der Lebsarkeit verwendet...

Über die Codegestaltung lässt sich ja bekanntlich streiten, aber das ist ein anderes (schon viel zu oft besprochenes) Thema.

Ich denke dieses hier ist auch abgeschlossen.

Ich persönlich gewöhne es mir gerade auch ab, ständig this zu schreiben. Das sind 5 Zeichen die der Compiler von sich aus schonmal "schreibt", und mir erspart bleiben. Leserlicher find ichs auch nicht.

Nur nochmal zur Klärung, StyleCop ist kein offizielles Tool von MS,
sondern ist von einem MS-Mittarbeiter in seiner Freizeit geschrieben.

Es gibt aber bei StyleCop genauso wie beim FXCop regeln, die keinen wirklichen sinn machen.

Hi,

Mehr zu sagen als die Anderen habe ich auch nicht zu sagen. Es ist wirklich nur Geschmackssache, ich will aber auch mal sagen, dass es auch Leute giebt, die das this besser/lesbarer finden (z.B. mich 🙂 ).

Gruß
Juy Juka

jo, und ich wollt das Standard-Beispiel noch umforumlieren:

public class Foo {
  public Foo(string name) {
    _name = name;
  }

  private string _name;

  public string Name {
    get { return _name; }
  }

Ihr könnt ja statt "_" sonstwas nehmen, dann klappts auch mit dem Member^^

und btw: this verwende ich praktisch nie, base schon deutlich öfter.

🙂

Xynratron

@JuyJuka
Endlich mal ein Gleichgesinnter 🙂
Ich verwende gerade bei Ableitungen von z.B. Controls sehr oft this, nur um besser im Code zu sehen, ist das jetzt eine Methode vom Basiscontrol, oder von dem jetzigen.

Plumpes Beispiel:

private void MachWas()
{
  this.BerechneWas();
  Invalidate();
}

Somit sehe ich sofort, das "BerechneWas" irgendwo in dieser Klasse deklariert wurde und "Invalidate" im Basiscontrol.

Naja, ist halt alles Geschmackssache...

Hallo Khalid,

es ist aber gefährlich, sich darauf zu verlassen, denn

private void MachWas()
{
  BerechneWas();
  this.Invalidate();
}

würde genauso gut compilieren. Was du vorgebracht hast, ist in meinen Augen also eher ein Argument gegen die Verwendung von this.

herbivore

private void MachWas()  
{  
  BerechneWas();  
  this.Invalidate();  
}  

witzigerweise ist genau das die variante die ich eine weile verwendet hab (aber auch nur bei controls)... ich hab mich mit mir aber drauf geeinigt, auch hier kein .this mehr zu verwenden.

Hallo,

Ich muss hier herbivore recht geben, so wie in dem Beispiel von Khalid ist this ungünstig benutzt.

Für mich gibt es nur eine "Regel" für die verwendung von this(und base): Entweder ganz oder garnicht!
Wenn this mal da steht und mal nicht, wird der Code nur wieder unleserlich. Und das "garnicht" unter gewissen Umständen nicht funktioniert plädiere ich immer für "ganz". (Hab die Bezeichnung die gewissen Umständen vergessen 😦, das mit der mehrfachen Deklaration der Namen (this.name und name, z.B.) )

Gruß
Juy Juka

(this.name und name, z.B.)

solcher code kommt bei uns garnicht erst zustande, da unsere membervariablen immer mit m_ beginnen, um cls-complient bleiben zu können.

Ist halt Geschmackssache 😉
Vielleicht trenne ich mich davon ja mal. Hab hier eh ein neues Projekt liegen, da könnte ich es ja mal versuchen. Ich benutze es einfach nur um fix zu sehen, wo die Methode herkommt.
Wobei man ja sicherlich auch einfach kurz mit der Maus rüberfahren könnte fällt mir gerade ein...

(this.name und name, z.B.)

solcher code kommt bei uns garnicht erst zustande, da unsere membervariablen immer mit m_ beginnen, um cls-complient bleiben zu können. Fällt dann aber wohl eher unter die Kategorie Namenskonventionen. Wird ja bekanntlich von Firma zu Firma anders gehandhabt.

Wir verwenden m_ nie, dafür aber in letzter zeit oft etwas wie strFoo oder objFoo für String und Object-Variablen.

naja wir arbeiten nach fxcop standard (oder besser gesagt annährend standard)

ungarische natation oder solche derivate soll man ohnehin nicht mehr verwenden. da c# typesafe ist und der typ eigendlich schon aus dem kontext her ersichtlich ist.

Nur nochmal zur Klärung, StyleCop ist kein offizielles Tool von MS,
sondern ist von einem MS-Mittarbeiter in seiner Freizeit geschrieben.

Das wusste ich gar nicht!

Trotzdem scheint MS die Meinung dieses Mitarbeiters zu vertreten, denn alle Klassen der .NET Framework Class Library, die ich bis jetzt gesehen habe, benutzen ".this" Prefixe genauso, wie es Stylecop vorschreibt, d.h. sowohl vor Membervariablen, als auch vor Memberfunktionen!

Du meinst echten Code von MS oder das, was der Reflector erzeugt?

das, was der Reflector erzeugt. Stimmt, ich hab ganz vergessen, dass das Orginal ja anders aussehen könnte...

Könnte sich vielleicht jemand mal ein zwei Originale von Microsoft anschauen und mir sagen, wie es darin ausschaut? Ich hab es bis jetzt nämlich noch nicht hinbekommen, mir den original source anzuschauen.

die frameworkklassen haben andere regeln, da sich gute styles erst mit der zeit bewährt haben und das framework von c++ entwicklern geschrieben wurde. daher ist das framework intern eher c++ style während sich der fxcop style eher als passend erwiesen hat. das beschreibt auch der besagte mitarbeiter in seinem blog zu seinem stylecop.

Hallo sowieso,

... weshalb der Code auch nicht als Entscheidungsgrundlage dienen kann bzw. sollte. Ich denke aber auch, dass in diesem Thread schon alles Wesentliche gesagt wurde, um selbst eine Entscheidung zu treffen. Mal abgesehen davon, dass es wichtigere Entscheidungen gibt. 🙂

herbivore

ich sehe den unterschied nur bei intellisense.

würde ich einfach drauflos schreiben, bekomme ich ne liste mit allen klassen, namespaces und was weiß ich noch.

wenn ich "this." schreibe, habe ich die member meiner klasse in der auflistung.
wäre aber nur ein kleiner vorteil. soweit ich das gehört habe, schreibt der compiler "this" automatisch vor klassenmembern.

Könnte sich vielleicht jemand mal ein zwei Originale von Microsoft anschauen und mir sagen, wie es darin ausschaut? Ich hab es bis jetzt nämlich noch nicht hinbekommen, mir den original source anzuschauen.

Ich habe bis vor kurzem in einem Microsoft Entwicklungszentrum gearbeitet (Neue App im Office/UC Bereich auf WPF Basis), dort hatten wir durchgehend "m_" (bzw. "s_" für static, "c_" für const) verwendet. War aber natürlich ein komplett anderes Team als das des Frameworks. Und ja, praktisch alle im Team hatten C++ "Erfahrung"...