C# - redundancja this. Dobre praktyki.

Czołem, przejdę od razu do sedna.

W trakcie mojej kariery poznałem wiele języków programowania. Najwięcej czasu spędziłem przy PHP i Javie.
PHP jako backend stron, Java do Androida i aplikacji desktopowych, w tym game developmentu.

Nie przeraża mnie nauka kolejnych technologii. Zainteresowałem się silnikiem Unity3D i koduję sobie w C#. Jako fan rozwiązań świetnego IDE firmy JetBrains, mam dostęp do jednego z produktów rodziny intelliJ IDEA - Rider.

I teraz najgłupsze pytanie, a może i jednak nie, cholera wie... ale nie zasnę dopóki nie poznam opinii fachowców.
IDE podpowiada mi, że korzystanie z wskazywania pochodzenia zmiennych do instancji, czyli forma this.zmienna jest redundantna i nie należy korzystać z tego zapisu. Dla programisty Javy i PHP to szok. Na videotutorialach również pomijane jest słowo this. Jak żyć?

... Dla programisty Javy (...) to szok....

Nie rozumiem. Byłem programistą Javy przez wiele lat (w tym 2,5 roku komercyjnie) i mało kto wstawiał niepotrzebnie this'a. W PHP programowałem krótko i nieobiektowo, więc się o nim nie wypowiem. Natomiast taki np Python wymaga użycia słówka kluczowego self w kółko jeśli chce się programować obiektowo. Java tego nie wymaga i się tego nie robi.

W Javie, C# (ale też Scali, C++, itd) słówka this używa się po to, aby np przekazać go gdzieś dalej albo po to by dostać się do przesłoniętych zmiennych. Jeśli nie ma przesłaniania to nie ma potrzeby używania this do dobierania się do zmiennych.

dualjack napisał(a):

nie zasnę

Wyluzuj :-)
Różne są zalecenia co do formatowania i pisania kodu, różne są też przyjęte konwencje w poszczególnych językach.
Nie ma o co kruszyć kopii.
Jak piszesz dla siebie to pisz jak chcesz (byle z sensem), jak w wieloosobowym projekcie to i tak trzeba się trzymać tego co obowiązuje w danym projekcie choćby się nam coś nie podobało.

Co do słowa this w C# to zwykle je pomijam, ale nie zawsze.

dualjack napisał(a):

IDE podpowiada mi, że korzystanie z wskazywania pochodzenia zmiennych do instancji, czyli forma this.zmienna jest redundantna i nie należy korzystać z tego zapisu.

To jest wymysł JetBrains, prawdopodobnie skutek nadmiernego spożywania napojów rozgrzewających w Sankt Petersburgu. Niektórzy rosyjscy agenci w Polsce też się tego stylu trzymają, niemniej jednak Microsoft od "prawie zawsze" zalecał używanie this. zamiast podkreślenia: https://blogs.msdn.microsoft.com/sourceanalysis/2008/05/25/a-brief-history-of-c-style/ http://stylecop.soyuz5.com/SA1101.html

Zasadniczo pisz jak wolisz, ważne aby było spójnie w projekcie. Ja np. teraz pracuję ze starymi ludźmi, więc używamy podkreślników, ale w swoich własnych projektach zawsze miałem this, podobnie w chyba wszystkich projektach do tej pory.

somekind napisał(a):

dualjack napisał(a):

IDE podpowiada mi, że korzystanie z wskazywania pochodzenia zmiennych do instancji, czyli forma this.zmienna jest redundantna i nie należy korzystać z tego zapisu.

Microsoft od "prawie zawsze" zalecał używanie this. zamiast podkreślenia: https://blogs.msdn.microsoft.com/sourceanalysis/2008/05/25/a-brief-history-of-c-style/ http://stylecop.soyuz5.com/SA1101.html

To ciekawe, co mówisz w kontekście C#. Gdyby tak było, to nowsze środowiska (np. już VS 2015) nie podpowiadałyby, że to niepotrzebne. Poza tym podkreślenie? Nie jest zgodne z konwencją nazewnictwa w C#. This można używać zawsze i wszędzie, jednak zazwyczaj nie ma sensu i MOŻE zaciemniać kod. This powinno używać się w wymaganych przypadkach:

• kiedy przekazujemy referencję do obiektu, np:

obj.DoSomeStuff(this);

• kiedy przypisujemy parametr metody (zazwyczaj konstruktora) do pola klasy o tej samej nazwie, np:

class MyClass
{
    int myVar;

    public MyClass(int myVar)
    {
        this.myVar = myVar;
    }
}

• z Twojego linku wynika jeszcze użycie pola z tej klasy, zamiast z klasy bazowej.

We wszystkich innych przypadkach (po prostu wołanie zwykłej metody, czy zwykłego pola) this nie ma sensu. W php jest wymagane:

$this->doSomeStuff();

Natomiast w C# nie jest to wymagane (poza przypadkami, o których napisałem oczywiście :)).
W C# doradzam używanie this tylko w tych przypadkach, w których trzeba, żeby bez sensu nie zaciemniać sobie kodu i nie zastanawiać się "czy ten this ma tu swoją przyczynę".

Kiedyś strasznie upierałem się żeby wszędzie obowiązkowo używać this. Dzisiaj używam tylko wtedy kiedy wymaga tego sytuacja, tak jak to napisał @Juhas. Zauważyłem też, że duże nagromadzenie this'ów zaczyna zaciemniać mi czytelność kodu i jednak jest lepiej kiedy linijka magicznie zmniejsza się o jedną trzecią przez usunięcie this. Podkreślenia dla pól prywatnych także nie używam i w zasadzie zawsze potrafię odróżnić pole prywatne od zmiennej lokalnej. Nie mam z tym problemów.

Może kiedyś mi się pozmienia...
BTW: projekty u nas też robione są bez this'ów.

Każde normalne IDE oznacza innym kolorem zmienne lokalne, globalne, zadeklarowane jako prywatne albo publiczne więc podkreślenia nie mają sensu. Visual Studio akurat jeszcze wtedy gdy go ostatnio używałem, nie robił tego o ile pamiętam (JetBrains/Android Studio to robi). Więc cóż, może i podkreślenia wtedy.

Juhas napisał(a):

W C# doradzam używanie this tylko w tych przypadkach, w których trzeba, żeby bez sensu nie zaciemniać sobie kodu i nie zastanawiać się "czy ten this ma tu swoją przyczynę".

Dlatego lepiej dodawać wszędzie i się nie zastanawiać. A przyczyna jest jasna - odróżnienie użycia instancyjnego elementu klasy od elementu statycznego.

Krzywy Programista napisał(a):

Każde normalne IDE oznacza innym kolorem zmienne lokalne, globalne, zadeklarowane jako prywatne albo publiczne więc podkreślenia nie mają sensu. Visual Studio akurat jeszcze wtedy gdy go ostatnio używałem, nie robił tego o ile pamiętam (JetBrains/Android Studio to robi). Więc cóż, może i podkreślenia wtedy.

Po pierwsze, to kod nie zawsze czyta się w IDE.
Po drugie jak niby kolorki w IDE rozwiązują ten problem?

public Class(string a)
{
    a = a;
}

@somekind twój zapis oznacza przypisanie zmiennej do samej siebie (tak przynajmniej jest w Javie), bo brana jest pod uwagę zmienna zadeklarowana najbliżej.

A co do kolorków, to w Android Studio (i InteliJ) tak to by wyglądało:

https://imgur.com/a/WJ8iF

Kolorki:

• nieużywane zmienne/klasy - szary
• zmienna globalna wyróżniona

..itd. Pamiętam, że swego czasu w VS mi tego brakowało, chociaż może Resharper albo jakaś inna wtyczka może to dodać (albo już nawet jest - nie wiem, nie jestem na czasie).

Bez this zmienna globalna też będzie wyróżniona, więc nie widzę sensu w stosowaniu this poza przypadkami takimi jak ten (niejednoznaczność).

Krzywy Programista napisał(a):

@somekind twój zapis oznacza przypisanie zmiennej do samej siebie (tak przynajmniej jest w Javie), bo brana jest pod uwagę zmienna zadeklarowana najbliżej.

No więc to jest dowód, że this się jednak przydaje, bo taki zapis jest jasny:

public Class(string a)
{
    this.a = a;
}

a jeśli ktoś nie chce używać this bo pochodzi z Węgier, to robi tak:

public Class(string a)
{
    _a = a;
}

..itd. Pamiętam, że swego czasu w VS mi tego brakowało, chociaż może Resharper albo jakaś inna wtyczka może to dodać (albo już nawet jest - nie wiem, nie jestem na czasie).

ReSharper to robi na pewno, a i nowsze VisualStudio może też.

Nikt nie mówi, że this się nie przydaje. Przydaje się do tego, żeby rozwiązać niejednoznaczność, ale nie jestem za tym, żeby zawsze stawiać this przy odwołaniu do pola klasy.

somekind napisał(a):

Po drugie jak niby kolorki w IDE rozwiązują ten problem?

Przecież @Juhas podał właśnie taki przykład jako uzasadnione użycie this.

Ostatnio w najnowszych produktach Microsoft wraca to praktyki z podkreśleniem, wystarczy przejrzeć kod np. ASP.NET Core: https://github.com/aspnet/Mvc/blob/dev/src/Microsoft.AspNetCore.Mvc.Core/ControllerBase.cs

Mi osobiście _ się podoba, ale zwykle dostosowuje się do istniejących zasad w projekcie.

W kod źródłowy od MS to nie masz co patrzeć. Wszelakie designery nieraz generują np kod z klamerkami w tej samej linii, pomimo tego MS zaleca w C# używanie klamerek w nowej linii bo to jest generalnie standard w .NET. To samo może być z podkreśleniami.

somekind napisał(a):

A kolorki w IDE nadal nie rozwiązują problemów składniowych.

W którym miejscu ktoś pisał, że kolorki w ide rozwiązują problemy składniowe? Kolorki w ide wystarczająco określają, czym jest zmienna i nie trzeba już w tym celu stosować this. Zaiste, this trzeba stosować w celu rozwiązania problemów składniowych, bo to po this wymyślono.

Ja myślę, że to tak samo jak z zaimkiem "ja". Oczywiście przydaje się wielce i trudno wyeliminować go z języka. Ja przypuszczam jednak, że używanie go z automatu wszędzie, gdzie tylko się da, byłoby ciut redundantne.

somekind napisał(a):

No więc to jest dowód, że this się jednak przydaje, bo taki zapis jest jasny:

Kopiuj

public Class(string a)
{
    this.a = a;
}

I niby R# w takim przypadku proponuje zamianę thisa na coś innego? W IntelliJu mi się takie propozycje nie zdarzyły ani w Javie ani w Scali.

Nie mam R# ale normalne VS nie proponuje nic w takim przypadku.