Jakie są obecnie uważane najlepsze praktyki dotyczące słowa kluczowego „this” przed polem i metodami w c #?

O ile nie jest potrzebne rozróżnienie między zmienną a polem o tej samej nazwie, nigdy nie umieszczam this.przed polem lub dostępem do elementu w języku C #. Uważam, że nie różni się to od m_przedrostka, który był powszechny w C ++, i myślę, że jeśli naprawdę musisz określić, że jest on członkiem, twoja klasa jest za duża.

Jednak w moim biurze jest wiele osób, które zdecydowanie się nie zgadzają.

Co uważa się za aktualne najlepsze praktyki this.?

EDYCJA: Aby wyjaśnić, nigdy nie używam m_i używam tylko this.wtedy, gdy jest to absolutnie konieczne.

Zgodnie z wytycznymi projektowymi dotyczącymi ram , odnosząc się do pól publicznych lub chronionych:

NIE używaj prefiksu dla nazw pól.

Na przykład m_jest przedrostkiem.

Tak więc publiczne ujawnienie pola nadaje się do użycia thissłowa kluczowego, jak wyjaśniono w MSDN

Aby zakwalifikować członków ukrytych pod podobnymi nazwami, na przykład: Kopiuj

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

Odnosząc się do prywatnych pól, możesz użyć, m_jeśli chcesz. Ale w obszarach publicznych zalecam stosowanie najlepszych praktyk.

Osobiście nie lubię znaków podkreślenia w moich nazwach zmiennych. Staram się też być konsekwentny. Jest więc this.name = name;dobrą praktyczną zasadą do pracy w obu scenariuszach publicznych / prywatnych.

W naszym zespole przyjęliśmy standard używania kwalifikatora this.lub Me.obiektu w większych klasach, aby pomóc młodym programistom łatwiej odróżnić dokładny / bezpośredni zakres zmiennej, patrząc na nią.

Pod względem kodu jest to całkowicie niepotrzebna zmiana, ale niczego nie blokuje, ponieważ i tak generuje dokładnie ten sam kod MISL. Przyjęliśmy go tylko dlatego, że rozwiązał natychmiastowy problem, który odkryliśmy u niektórych juniorów. Poza tym nie uważam, aby było to pomocne.

StyleCop wymusi użycie this.So, więc jeśli uważasz to za najlepszą praktykę (co ja robię), to użycie this.jest najlepszą praktyką.

Styl, który zastosujesz, zależy od Ciebie i twoich własnych standardów kodowania, „najlepszy” jest tym, czym go zdefiniujesz. Po prostu bądź konsekwentny. Niespójne używanie go prowadzi do zamieszania.

Moje rozumowanie jest takie, że użycie this.wywołuje fakt, że odwołujesz się do właściwości instancji, więc na przykład pomaga podkreślić fakt, że mutujesz je (jeśli masz this.x = ...), o czym możesz chcieć wiedzieć. Podkreśla również fakt, że za każdym razem, gdy zobaczysz this.metodę, nigdy nie będzie ona statyczna. Zrobi m_to również przy użyciu jakiejś konwencji , ale to ręczny wysiłek, jeśli przekształcisz się m_w statyczny lub zmienisz metodę na przekazanie wartości spoza klasy, musisz pamiętać, aby zmienić nazwę, jeśli używasz thiswtedy kompilator zmusi cię do wprowadzenia zmiany.

thisUpraszczając, używanie jest łatwiejsze, ponieważ jeśli się pomylisz, kod nie będzie się kompilował, jeśli m_go użyjesz, to będzie to wysiłek ręczny i nie będziesz korzystać z narzędzi.

Jedną z fajnych rzeczy w używaniu m_jest to, że jak tylko wpiszesz małą minteligencję, otrzymasz listę wszystkich twoich prywatnych zmiennych, osobiście uważam, że jest to plus na jej korzyść; Z podobnych powodów s_wybrałbym też prywatną statykę i c_stałe prywatne. To węgierska notacja, ale w tym sensie, że miała na myśli, ponieważ dodaje użyteczne znaczenie do nazwy zmiennej, aby każdy inny programista mógł powiedzieć o niej z nazwy, co może nie być całkowicie oczywiste.

Z pewnością nie zgadzam się z brakiem możliwości rozróżnienia między zmiennymi składowymi i zmiennymi, ponieważ są one różne, a kiedy czytam kod, w którym ludzie nie robią czegoś, aby go rozróżnić, jest to naprawdę trudniejsze do odczytania. Korzystanie this.po prostu wydaje się więcej płyty kotła niż jest to konieczne. Ale tak naprawdę to jest osobisty gust, jeśli przez jakiś czas kodujesz w jeden sposób, to ostatecznie myślisz, że to jest właściwe, a wszystko inne jest złe. Jedyne, co naprawdę ma znaczenie, jeśli plan jest rozsądny, to to, że wszyscy w zespole są konsekwentni.

thisjest wyraźny. To znak optyczny, którego nie możesz przegapić.

Prawie zawsze wolę kod jawny niż kod niejawny. Dlatego thisczęsto używam . Uważam to za najlepszą praktykę.

Zawsze używam „tego”. Rozumowanie opiera się na dwóch prostych faktach:

• Czytanie kodu jest trudniejsze niż pisanie kodu.
• Czytasz kod częściej niż piszesz.

Użycie „tego” wyraźnie mówi każdemu, kto czyta (tj. Nie tylko autorowi, ale może uwzględnić autora w ciągu 6 miesięcy po całkowitym zapomnieniu o szczegółach implementacji), że tak, to jest członek klasy, którą „ mówię o tutaj. „m_” i tym podobne to tylko konwencja i jak każda inna konwencja może być niewłaściwie używana (lub w ogóle nie używana) - nie ma nic do wymuszenia „m _” / etc w czasie kompilacji lub w czasie wykonywania. „to” jest silniejsze: możesz umieścić „m_” na zmiennej lokalnej, a kompilator nie będzie narzekał; nie możesz tego zrobić z „tym”.

Jeśli cokolwiek uważam za godne ubolewania, że ​​użycie „tego” nie było obowiązkowe w specyfikacjach językowych.

Jako dobry bonus, podczas debugowania możesz najechać myszką na „to” (lub dodać zegarek) i uzyskać kontrolę wszystkich innych członków klasy - cenne informacje.

Słowo thiskluczowe jest używane szczególnie do rozróżnienia 2 istniejących zmiennych, szczególnie gdy masz konstruktor lub metodę ze zmienną o tej samej nazwie, ale może mieć ten sam typ.

Przykład:

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;
    }
}

To (np. this.reason = reason) W zasadzie przypisuje wartość z parametrów do zmiennych w klasie. thisw zasadzie bierze klasę reasonz bloku parametrów.

Zastanawiałem się nad tym od jakiegoś czasu. Po wykonaniu obszernego kodowania w javascript, przyłapałem się na częstszym używaniu this.w moim kodzie c # (wcześniej użyłem go prawie wyłącznie w konstruktorach lub podobnych metodach, aby uniknąć dwuznaczności). To sprawia, że ​​kod jest nieco bardziej przejrzysty przy niewielkim dodatkowym wysiłku, ponadto nie okaleczasz nazw członków klasy prefiksami i nadal możesz powrócić do używania członków „na krótką metę”, gdy kontekst jest jasny lub w szczególnie skomplikowanych instrukcjach. Po prostu dodaję this., gdy mam dłuższą metodę, dłuższą listę argumentów lub wiele zmiennych lokalnych i myślę, że kod może zyskać na dodatkowej przejrzystości, nawet jeśli jest wymuszony.

Ale ja osobiście absolutnie nienawidzę m_stylu prefiksu, nie tyle ze względu na węgierski, ale dlatego, że podkreślenie jest trudnością w pisaniu;) Więc nie uważam tego za alternatywę. Przyznaję, że ma to swoje mocne strony, jeśli chodzi o inteligencję, jednak możesz ponownie argumentować, że jeśli nie pamiętasz pierwszych kilku liter zmiennej członka, twoja klasa jest za duża.

Zapowiadam pojedynczy prefiks podkreślenia dla członków klasy. _someVar;

Dlaczego? Na pierwszy rzut oka wiesz, że to członek, a nie zmienna stosu. Tylko wygoda na pierwszy rzut oka. I zajmuje mniej bałaganu w porównaniu ze słowem kluczowym „to”.

Używanie rzeczy takich jak this.przedrostek / słowo kluczowe, które nie są konieczne ani nie zmieniają wyniku, są zawsze subiektywne. Myślę jednak, że możemy się zgodzić, że większość z nas chce odróżnić pola od zmiennych lokalnych. Niektórzy używają prefiksu podkreślenia (co uważam za brzydkie i rodzaj węgierskiego zapisu), inni używają this.słowa kluczowego. Jestem jednym z tych ostatnich. Chodzi przede wszystkim o czytelność i zrozumiałość. Nie mam nic przeciwko wpisywaniu odrobiny dodatkowej, jeśli jest wyraźniejsza lub bardziej czytelna. Chcę różnicować pola i zmienne w mgnieniu oka.

Zawsze definiuję pola o nazwach podobnych myFieldi nazwach parametrów oraz nazwy zmiennych lokalnych również podobne do myField. Bez podkreślników, bez prefiksów. Używam thiswszędzie, gdzie mówię o polu. W ten sposób mogę odróżnić pola od lokalnych zmiennych i argumentów bez żadnego prefiksu. Oczywiście w takim przypadku thiswymagane jest słowo kluczowe:

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

Moje właściwości wyglądają więc tak (tak, zawsze umieszczam pole z właściwością, a nie gdzieś niezwiązane na górze mojego pliku):

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

Ładnie brzmi: zwróć to imię .

EDYCJA: Moja odpowiedź wyraźnie nie jest odpowiedzią. Oto edycja. Wytyczne Microsoft dotyczące kodowania stanowią:

2.6 Nazewnictwo

Nie używaj prefiksu dla zmiennych składowych ( , m , s_ itp.). Jeśli chcesz rozróżnić> między zmiennymi lokalnymi i zmiennymi składowymi, powinieneś użyć „tego”. w C # i „Me”. w VB.NET.

Można znaleźć na stronie : http://blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspx

Wydaje się więc, że przynajmniej od stwardnienia rozsianego nie ma jasnej wytycznej, chociaż inna odpowiedź mówi, że StyleCop czyni ją wytyczną. Nie ma autorytetu w tych sprawach, więc sugeruję, abyś podjął decyzję, albo w tym przypadku poddaj się swojemu zespołowi. To nie jest taka wielka sprawa.

Moja oryginalna odpowiedź osobiście się z tobą zgadzam, ale być może cenny byłby test czytania ze zrozumieniem porównujący obie metody. W przeciwnym razie te rzeczy są po prostu mętne.

Moja salwa do naśladowania: moim zdaniem ludzie niepotrzebnie komplikują swój styl kodu, a jeśli muszą wskazać, że coś jest zmienną na poziomie klasy, mogą występować inne poważne problemy strukturalne w kodzie, takie jak stara metoda receptur umieszczanie zmiennych prywatnych na szczycie klasy, które zmuszają cię do ciągłego przewijania w górę i w dół.

uderza mnie to jako jedna z tych konwencji „czym to jest” w porównaniu z prawidłowymi konwencjami nazewnictwa „co robi”. Zwartość powinna być preferowana powyżej jawności. Ta lekcja jest często powtarzana przez dynamiczne języki. Nie potrzebujemy całego puchu!

to. często może prowadzić do niepożądanego hałasu.

Oto moje rozwiązanie:

• nazwa_parametru
• zmienne_lokalne
• ANY_CONSTANT
• _private_members
• NonPrivateProperties
• _NonPrivateProperty // Backer
• własność prywatna
• _privateProperty // backer