Wanneer jy gebruik maak van die "dit" navraag?[gesluit]

Question

Ek was nuuskierig oor hoe ander mense gebruik om die hierdie navraag.Ek is geneig om dit te gebruik in die vervaardigerskampioenskap, maar ek kan dit ook gebruik in die hele klas in ander metodes.'n paar voorbeelde:

In'n konstruktor:

public Light(Vector v)
{
    this.dir = new Vector(v);
}

Elders

public void SomeMethod()
{
    Vector vec = new Vector();
    double d = (vec * vec) - (this.radius * this.radius);
}

Answer 1

Daar is 'n hele paar gebruike van hierdie navraag in C #.

1. Om lede weggesteek deur soortgelyke kwalifiseer noem
2. Om 'n voorwerp het slaag self as 'n parameter na ander metodes
3. Om 'n voorwerp terugkeer self uit 'n metode het
4. Om index verklaar
5. Om uitbreiding metodes
verklaar
6. Om parameters tussen vervaardigerskampioenskap slaag
7. intern toewys waarde tipe (struct) waarde .
8. Om 'n uitbreiding metode op die huidige geval roep
9. Om self na 'n ander tipe gegooi
10. Om ketting vervaardigerskampioenskap gedefinieer in dieselfde klas

Jy kan die eerste gebruik vermy deur nie met lid en plaaslike veranderlikes met dieselfde naam in omvang, byvoorbeeld deur volgende algemene benaming konvensies en die gebruik van eiendomme (Pascal geval) in plaas van velde (kameel geval) om te verhoed dat 'n botsing met plaaslike veranderlikes (ook kameel geval). In C # kan 3.0 velde omgeskakel word na eiendomme maklik deur die gebruik van -motor geïmplementeer eienskappe .

Answer 2

Ek bedoel nie hierdie om snarky klink, maar dit maak nie saak.

Ernstig.

Kyk na die dinge wat belangrik is: jou projek, jou kode, jou werk, jou persoonlike lewe. Nie een van hulle gaan hul sukses rus op die vraag of jy die "hierdie" navraag te gebruik om toegang te kwalifiseer om velde. Die hierdie navraag sal nie help om te skip op tyd. Dit gaan nie om foute te verminder, dit is nie van plan om enige noemenswaardige uitwerking op-kode gehalte of instandhouding hê. Dit gaan nie om jou te kry 'n verhoging, of toelaat dat jy minder tyd spandeer by die kantoor.

Dit is regtig net 'n styl kwessie. As jy wil "hierdie", gebruik dit dan. As jy dit nie doen nie, doen dan nie. As jy dit nodig het om korrek semantiek kry gebruik dit dan. Die waarheid is, elke programmeerder het sy eie unieke programing styl. Wat styl weerspieël opvattings van wat die "mees mooi kode" moet lyk daardie spesifieke programmeerder se. Per definisie, is 'n ander programmeerder wat jou kode lees gaan na 'n ander programing styl het. Dit beteken dat daar is altyd iets te wees iets wat jy het dat die ander man hou nie, of sou anders gedoen het. Op 'n stadium 'n man gaan jou kode te lees en mor oor iets.

Ek sou nie verknies oor dit. Ek wil net seker maak die kode is as mooi as moontlik volgens jou eie smaak. As jy 10 programmeerders vra hoe om kode formaat, gaan jy ongeveer 15 verskillende menings te kry. 'N Beter ding om te fokus op hoe die kode is ingereken. Is dinge onttrek reg? Het ek kies betekenisvolle name vir dinge? Is daar 'n baie-kode duplisering? Is daar maniere kan ek dinge te vereenvoudig? Aan die dinge reg, dink ek, sal die grootste positiewe impak op jou projek, jou kode, jou werk, en jou lewe te hê. Toevallig, dit sal waarskynlik ook die ander ou om die minste te mor veroorsaak. As jou kode werk, is maklik om te lees, en is goed ingereken, die ander man is nie van plan om te spandeer om hoe jy inisialiseer velde. Hy is net gaan om jou kode, verwonder gebruik by dit se grootheid, en dan beweeg op na iets anders.

Answer 3

Ek gebruik dit net wanneer dit absoluut nodig, met ander woorde, wanneer 'n ander veranderlike is 'n ander oorskadu. Soos hier:

class Vector3
{
    float x;
    float y;
    float z;

    public Vector3(float x, float y, float z)
    {
        this.x = x;
        this.y = y;
        this.z = z;
    }

}

Of as Ryan Fox wys daarop, wanneer jy dit nodig om hierdie te slaag as 'n parameter. (Plaaslike veranderlikes het voorrang bo lid veranderlikes)

Answer 4

Persoonlik, het ek probeer om altyd gebruik hierdie wanneer daar verwys word na lid veranderlikes. Dit help verduidelik die kode en maak dit meer leesbaar. Selfs al is daar geen dubbelsinnigheid, iemand lees deur my-kode vir die eerste keer weet nie wat nie, maar as hulle sien hierdie konsekwent gebruik, sal hulle weet of hulle is op soek na 'n lid veranderlike of nie .

Answer 5

Ek gebruik dit elke keer as ek verwys na 'n geval veranderlike, selfs al is ek nie hoef te. Ek dink dit maak die kode meer duidelik.

Answer 6

Ek kan nie glo al die mense wat sê wat dit gebruik altyd 'n "beste praktyk" en so.

Gebruik "hierdie" as daar dubbelsinnigheid, soos in voorbeeld Corey se of wanneer jy dit nodig om die voorwerp te slaag as 'n parameter, soos in Ryan se voorbeeld . Daar is geen rede om dit anders te gebruik, want dit kan 'n veranderlike wat gebaseer is op die omvang ketting los duidelik genoeg dat kwalifiserende veranderlikes daarmee moet onnodig moet wees.

EDIT: Die C # dokumentasie oor "hierdie" dui een meer gebruik, behalwe die twee wat ek genoem het, vir die "hierdie" navraag - vir die verklaring index

EDIT: @Juan: Huh, ek weet nie enige teenstrydigheid sien in my stellings - daar is 3 gevalle waar ek die "hierdie" navraag sou gebruik (soos gedokumenteer in die C # dokumentasie), en dit is tye wanneer jy eintlik behoefte dit. Vas "hierdie" in die voorkant van veranderlikes in 'n konstruktor wanneer daar geen oorskadu aangaan is bloot 'n vermorsing van toetsaanslagen en 'n mors van my tyd vir lees nie, dit bied geen voordeel.

Answer 7

Ek gebruik dit wanneer StyleCop vertel my om. StyleCop moet gehoorsaam. O ja.

Answer 8

Enige tyd wat jy 'n verwysing na die huidige voorwerp nodig.

Een veral handig scenario is wanneer jou voorwerp doen 'n beroep 'n funksie en wil self slaag daarin.

Voorbeeld:

void onChange()
{
    screen.draw(this);
}

Answer 9

Ek is geneig om dit te gebruik oral so goed, net om seker te maak dat dit duidelik is dat dit byvoorbeeld lede wat ons te doen het met.

Answer 10

Ek gebruik dit oral daar dalk onduidelikheid (natuurlik). Nie net samesteller dubbelsinnigheid (dit in so 'n geval sou vereis word), maar ook onduidelikheid vir iemand te kyk na die kode.

Answer 11

Nog 'n bietjie skaars gebruik vir die hierdie navraag is wanneer jy dit nodig om 'n eksplisiete koppelvlak implementering roep vanuit die implementering van die klas. Hier is 'n geforseerde voorbeeld:

class Example : ICloneable
{
    private void CallClone()
    {
        object clone = ((ICloneable)this).Clone();
    }

    object ICloneable.Clone()
    {
        throw new NotImplementedException();
    }
}

Answer 12

Hier is wanneer ek dit gebruik:

• Toegang Private metodes vanuit die klas (onderskei)
• Die slaag die huidige voorwerp na 'n ander metode (of as 'n sender voorwerp, in die geval van 'n gebeurtenis)
• Wanneer die skep van uitbreiding metodes: D

Ek het nie hierdie gebruik vir Private velde omdat ek voorvoegsel private veld veranderlike name met 'n onderstreep (_).

Answer 13

[C ++]

Ek stem saam met die "gebruik dit wanneer jy" brigade. Versier kode onnodig met hierdie is nie 'n goeie idee, want die samesteller jy nie sal waarsku wanneer jy vergeet om dit te doen. Dit stel potensiële verwarring vir mense verwag hierdie om altyd daar wees, dit wil sê hulle sal moet dink daaroor.

So, wanneer sal jy dit gebruik? Ek het net 'n blik rondom 'n paar random kode en gevind hierdie voorbeelde (ek is nie veroordeel of dit goeie dinge om te doen of andersins):

• Die slaag "jouself" om 'n funksie.
• Toewys "jouself" om 'n wyser of iets soos dit.
• Casting, dit wil sê op / af beslissende (veilig of andersins), gooi constness, ens.
• Vertalerkonstruksie afgedwing dubbelsinnigheidsbladsy.

Answer 14

Ek gebruik dit wanneer, in 'n funksie wat 'n verwysing na 'n voorwerp van dieselfde tipe aanvaar, ek wil dit duidelik wat beswaar Ek verwys na waar.

Byvoorbeeld

class AABB
{
  // ... members
  bool intersects( AABB other )
  {
    return other.left() < this->right() &&
           this->left() < other.right() &&

           // +y increases going down
           other.top() < this->bottom() &&
           this->top() < other.bottom() ;
  }
} ;

(vs)

class AABB
{
  bool intersects( AABB other )
  {
    return other.left() < right() &&
           left() < other.right() &&

           // +y increases going down
           other.top() < bottom() &&
           top() < other.bottom() ;
  }
} ;

By 'n kort wat AABB doen right() verwys na? Die this voeg 'n bietjie van 'n Verduideliker.

Answer 15

In Jakub Šturc se antwoord sy # 5 oor die verbygaan data tussen contructors waarskynlik kon 'n bietjie verduideliking gebruik. Dit is in oorlading konstruktors en is die een geval waar die gebruik van this is verpligtend. In die volgende voorbeeld kan ons die parameters konstruktor van die parameterless constructor bel met 'n standaard parameter.

class MyClass {
    private int _x
    public MyClass() : this(5) {}
    public MyClass(int v) { _x = v;}
}

Ek het gevind dat hierdie 'n besonder nuttige funksie by geleentheid wees.

Answer 16

Jy moet altyd gebruik, ek gebruik dit om private velde en parameters diferantiate (want ons benoemings konvensies staat dat ons nie voorvoegsels gebruik vir name lid en parameter (en hulle is gebaseer op inligting wat op die internet, so ek is van mening dat 'n beste praktyk))

Answer 17

Ek het in die gewoonte van die gebruik daarvan mildelik in Visual C ++ sedert dit te doen sou IntelliSense wat ek druk die ">" sleutel aktiveer, en ek is lui. (En geneig is tot typos)

Maar Ek het voortgegaan om dit te gebruik, want ek vind dit handig om te sien dat ek 'n beroep 'n lid funksie eerder as 'n globale funksie.

Answer 18

Ek is geneig om te velde met onderstreep _ so nie regtig ooit nodig het om dit te gebruik. Ook R # geneig om hulle refactor weg in elk geval ...

Answer 19

Ek gebruik pretty much net hierdie wanneer verwys na 'n tipe eiendom van die binnekant van dieselfde tipe. As 'n ander gebruiker genoem, ek beklemtoon ook plaaslike velde so hulle is opvallend sonder hierdie .

Answer 20

Ek gebruik dit net wanneer dit nodig is, behalwe vir simmetriese bedrywighede wat as gevolg van enkele argument polimorfisme het om in die metodes van die een kant word:

boolean sameValue (SomeNum other) {
   return this.importantValue == other.importantValue;
} 

Answer 21

[C ++]

hierdie word gebruik in die opdrag operateur waar die meeste van die tyd wat jy het om seker te maak en te verhoed dat vreemde (onbedoelde, gevaarlik, of net 'n vermorsing van tyd vir die program) dinge soos:

A a;
a = a;

Jou opdrag operateur sal geskryf:

A& A::operator=(const A& a) {
    if (this == &a) return *this;

    // we know both sides of the = operator are different, do something...

    return *this;
}

Answer 22

this op 'n C ++ vertaler

Die C ++ compiler sal stilweg lookup vir 'n simbool as dit dit nie onmiddellik vind. Soms, die meeste van die tyd, dit is 'n goeie:

• die gebruik van die moeder klas 'metode as jy dit nie het oorlaai in die kind klas.
• die bevordering van 'n waarde van 'n tipe na 'n ander tipe

Maar soms, Jy wil net nie die samesteller om te raai. Jy wil die samesteller na pick-up die regte simbool en nie 'n ander.

Vir my , dié keer is wanneer, binne 'n metode, ek wil om toegang te verkry tot 'n lid metode of lid veranderlike. Ek wil net nie 'n paar random simbool opgetel net omdat ek geskryf printf in plaas van print. this->printf sou nie saamgestel.

Die punt is dat, met C nalatenskap biblioteke (§), nalatenskap kode geskryf jaar gelede (§§), of wat ook al kan gebeur in 'n taal waar kopie / plak is 'n verouderde, maar nog steeds aktief funksie, soms, vertel die samesteller om nie te speel Wits is 'n goeie idee.

Dit is die redes wat ek gebruik this.

(§) dis nog 'n soort raaisel vir my, maar ek nou wonder of die feit dat jy die kop in jou bron, is die rede al die nalatenskap C biblioteke simbole sal jou globale naamruimte besoedel

(§§) besef dat "wat jy nodig het om 'n kop in te sluit, maar dat met hierdie kop sal jou kode te breek omdat dit gebruik maak van 'n paar stom makro met 'n generiese naam" is een van daardie Russiese roulette oomblikke van die lewe 'n kodeerder se

Answer 23

'hierdie. " help vind lede op 'hierdie 'n klas met 'n baie lede (gewoonlik as gevolg van 'n diep erfenis ketting).

Slaan Ctrl + Ruimte help nie met hierdie, want dit sluit ook vorme; waar-as 'hierdie. " sluit lede SLEGS.

Ek verwyder gewoonlik dit eens ek het wat ek was na: maar dit is net my styl deurbreek

.

In terme van styl, as jy 'n eensame-veldwagter - jy besluit; as jy werk vir 'n maatskappy vashou aan die maatskappy se beleid (kyk na die dinge in bron beheer en te sien wat ander mense doen). In terme van die gebruik daarvan aan lede kwalifiseer nie, is reg of verkeerd. Die enigste verkeerde ding is teenstrydigheid - dit is die goue reël van styl. Laat die-neet pluk ander. Spandeer jou tyd gepeins real kodering probleme - en natuurlik kodering -. In plaas

Answer 24

Dit hang af van die kodering standaard ek werk onder. As ons gebruik _ om 'n geval veranderlike dui dan "hierdie" oorbodig. As ons dit nie gebruik _ dan ek is geneig om dit te gebruik om byvoorbeeld veranderlike dui.

Answer 25

Ek gebruik dit om te roep IntelliSense net soos JohnMcG , maar ek sal terug te gaan en uit te wis" hierdie-> "wanneer ek klaar is. Ek volg die Microsoft konvensie van voorvoegsel lid veranderlikes met "m_", so laat dit as dokumentasie sal net onnodige wees.

Answer 26

1 - Common Java setter idioom:

 public void setFoo(int foo) {
     this.foo = foo;
 }

2 - Wanneer jy 'n funksie met hierdie voorwerp as 'n parameter

notifier.addListener(this);

Answer 27

Ek gebruik dit elke keer as ek kan. Ek glo dit maak die kode meer leesbare, en nog baie meer leesbare kode gelyk minder foute en meer instandhouding.

Answer 28

As jy baie ontwikkelaars werk op dieselfde kode basis, moet jy 'n paar kode riglyne / reëls. Waar ek werk het ons desided om te gebruik 'hierdie' op velde, eienskappe en gebeure.

Vir my is dit maak goeie sin om dit te doen soos hierdie, dit maak die kode makliker om te lees wanneer jy onderskei tussen klas-veranderlikes en metode-veranderlikes.

Answer 29

Daar is een gebruik wat nie reeds genoem in C++, en dit is nie om te verwys na die eie voorwerp of disambiguate'n lid van'n ontvang veranderlike.

Jy kan gebruik this om te omskep in'n nie-afhanklike naam in'n argument afhanklik naam binne sjabloon klasse wat die besit van ander templates.

template <typename T>
struct base {
   void f() {}
};

template <typename T>
struct derived : public base<T>
{
   void test() {
      //f(); // [1] error
      base<T>::f(); // quite verbose if there is more than one argument, but valid
      this->f(); // f is now an argument dependent symbol
   }
}

Templates is saamgestel met'n twee slaag meganisme.Gedurende die eerste slaag, slegs nie-argument afhanklik name opgelos word en nagegaan word, terwyl afhanklik name nagegaan word net vir samehang, sonder om werklik die vervanging van die sjabloon argumente.

Op daardie stap, sonder om werklik die vervanging van die tipe, die samesteller het byna geen inligting wat base<T> kan word (let daarop dat die spesialisering van die basis sjabloon kan draai dit in heeltemal verskillende soorte, selfs ongedefinieerde tipes), so dit net aanvaar dat dit is'n tipe.Op hierdie stadium is die nie-afhanklike bel f dit lyk net natuurlike na die programmeerder is'n simbool dat die vertaler moet vind as'n lid van die derived of in die omringende namespace-wat nie gebeur nie in die voorbeeld-en dit sal kla nie.

Die oplossing is om die draai van die nie-afhanklike naam f in'n afhanklik naam.Dit kan gedoen word in'n paar maniere, deur uitdruklik verklaar die tipe waar dit geïmplementeer word (base<T>::f --die toevoeging van die base<T> maak die simbool afhanklik van T en die samesteller sal net aanvaar dat dit sal bestaan en uitgestel die werklike tjek vir die tweede slaag, na die argument te vervang.

Die tweede manier, baie sorteer as jy erf van templates wat meer as een argument, of lang name, is net die toevoeging van'n this-> voor die simbool.As die sjabloon klas jy is die uitvoering van nie afhang van'n argument (dit erf uit base<T>) this-> is die argument afhanklik, en ons kry die dieselfde resultaat: this->f is nagegaan in die tweede ronde, na sjabloon parameter te vervang.

Answer 30

Jy moet nie gebruik "hierdie" nie, tensy jy absoluut moet.

Daar is 'n boete wat verband hou met onnodige breedsprakigheid. Jy moet streef na-kode dit is presies so lank as wat dit nodig het om te wees, en nie meer nie.