Jak w temacie. Czy używacie this przed nazwami metod albo pól klasy? A może nie używacie...
Głosować :)
PS: Uzasadnienie wyboru zalecane. Ja używam właściwie odkąd pamiętem, bo kiedy napiszę this. to dostaje wyłącznie pola obiektu albo metody, w którym jestem i jest mi wygodniej. Tylko później tych słówek this w kodzie jest pełno, co mi nie przeszkadza specjalnie ale jestem ciekaw Waszego zdania.
Różnie.
I zależnie od języka: w C++ samo Method() może być funkcją globalną i tego nie widać.
W C# takiego problemu nie było, a najeżenie tych thisów szpeci kod ;-) - ale z tego co kojarzę już C# "zepsuto" pod tym względem bo można wciągać metody z innej klasy...
Ustawiłem IDE by kolorowało mi pola na inny kolor niż zmienne lokalne/globalne, tak samo metody klas, więc nie potrzebuję this żeby na pierwszy rzut oka wiedzieć co to jest. A osobiście nie cierpię niepotrzebnych prefiksów, czy to this->, czy też std::.
Przed metodą nigdy, przed polem gdy jest konflikt nazw - istnieją pole i zmienna lokalna o takiej samej nazwie. Czasami również wtedy gdy konfliktu nie ma:
int a;
int b;
double c;
public Konstruktor(int a, int b)
{
this.a = a;
this.b = b;
this.c = Math.random(); // this jest zbyteczne, ale kod ładniej wygląda
}
Głosuję na nie.
Nie używam tam, gdzie nie trzeba, bo redundancja to zło.
Oczywiście, że przed nazwą pola trzeba używać. Wygląda bardziej przejrzyście, bo od razu wiadomo, że nie jest to zmienna lokalna.
Wygląda bardziej przejrzyście, bo od razu wiadomo, że nie jest to zmienna lokalna.
Przecież to powinna załatwić odpowiednia konwencja nazewnictwa zmiennych...
Tokarz_ napisał(a):
Oczywiście, że przed nazwą pola trzeba używać. Wygląda bardziej przejrzyście, bo od razu wiadomo, że nie jest to zmienna lokalna.
Nie sądzisz, że coś tak prostego powinno załatwiać IDE? IntelliJ dla przykładu w każdej standardowej skórce inaczej koloruje zmienne instancyjne.
Osobiście mam zdanie takie jak@bogdans i @twonek.
No... wynik wyrównany. Przewaga co rusz przechodzi z rąk do rąk.
sporadycznie przy polach gdy musze. nie zdarza mi sie nie odrozniac pol od parametrow, imo nie byloby glupie zeby 'this' w ogole wyeliminowac ze skladni c# czy javy (jasne, za pozno)
W pracy używałem GitLaba, gdzie jest kolorowanie składni przy diffach/code review. W dodatku można wybrać sobie skórkę.
Generalnie najważniejsze to trzymać się konwencji w projekcie. Jeśli this nie był do tej pory używany, a ktoś zacznie go nagle stosować w dopisywanych przez siebie linijkach, to kod zacznie wyglądać jak kupa. Podobnie, jeśli jakiś miłośnik fałszywie pojmowanego braku redundancji przestanie się trzymać konwencji używania this.
W kodzie ważna jest czytelność i jednoznaczność. Zapewne niektórzy nazwą zmienną ups zamiast userProfileService i nazwą to "brakiem redundancji". Ale to nie będzie ani czytelne, ani jednoznaczne.
Podobnie ma się sprawa z this. To słowo daje jednoznaczną i błyskawiczną informację na temat tego, czy mamy do czynienia z polem czy zmienną, albo metodą instancyjną, a nie statyczną. Dlatego w swoim kodzie je stosuję, bo dla mnie to jest bardzo wygodne.
Niektórzy argumentują, że rozróżniać rodzaje pól i metod powinno IDE. Świetnie, ale czasem istnieje potrzeba przeczytania kodu, z którego się korzysta, ale nie ma potrzeby pobierania jego źródeł. Jak ktoś słyszał o możliwości korzystania z zewnętrznych bibliotek, podejściu SOA albo mikroserwisach, to pewno zrozumie o co chodzi. Nie każdą przeglądarkę kodu online da się skonfigurować do zaawansowanego kolorowania, w szczególności o ile wiem, GitHuba się nie da, dlatego warto dbać o czytelność na poziomie kodu, a nie narzędzi.
W Gosu *this *jest wymagane.
Ja dla członków klasy dodaję '_' po nazwie zmiennej, np Config config_;.
W sumie nieważna jest konwencja, ważne jest jedynie, aby była spójna dla całego projektu.
Ja używam this tylko kiedy odnosze się do właściwości instancji (w C#).
aurel napisał(a)
Przecież to powinna załatwić odpowiednia konwencja nazewnictwa zmiennych...
Błe, podkreślnik przed zmienną? Masochizm/sadyzm.
aurel napisał(a)
Nie używam tam, gdzie nie trzeba, bo redundancja to zło.
this. to redundancja, a nadmiarowy podkreślnik nie?
Zresztą, nie mam żadnego Twojego kodu w C# teraz pod ręką, ale jesteś pewna że nie masz nigdzie celowo żadnej nadmiarowości w kodzie? W C# sporo słów kluczowych jest opcjonalnych, a jednak regularnie dodawanych.
_ jest zalecane przez "Framework Design Guidelines" czyli jak klepiesz .NET Framework to spoko używaj _ dla całej reszty śmiertelników zalecane jest używanie this.. - DibbyDum dzisiaj, 15:37
Odnośnie reszty śmiertelników:
https://msdn.microsoft.com/en-us/library/ms229045.aspx - X DO NOT use underscores, hyphens, or any other nonalphanumeric characters.
https://msdn.microsoft.com/en-us/library/ta31s3bc(v=VS.71).aspx - Do not use Hungarian notation for field names. Good names describe semantics, not type. Do not apply a prefix to field names or static field names. Specifically, do not apply a prefix to a field name to distinguish between static and nonstatic fields. For example, applying a g_ or s_ prefix is incorrect.
sporadycznie przy polach gdy musze. nie zdarza mi sie nie odrozniac pol od parametrow, imo nie byloby glupie zeby 'this' w ogole wyeliminowac ze skladni c# czy javy (jasne, za pozno)
Bez przesady, nie można wyeliminować this bo this ma kilka zastosowań gdzie go się nie da zastąpić (przykładowo: void Asdf() { RegisterSomething(this); })
katelx napisał(a)
nie no, to wlasnie ten przypadek gdy 'musze'. chialabym zeby skladnia wymuszala ze np. nie mozna przypisywac nic do parametrow lub cos w tym stylu, przez co
nie trzeba by bylo uzywac zadnych magicznych prefixow - katelx wczoraj, 16:06
Nie podoba mi się takie rozwiązanie, bo jest magiczne. Na przykład wtedy foo może się odnosić do dwóch różnych zmiennych w jednym scope - z tego co wiem, to by było rozwiązanie unikalne na skalę języków programowania z leksykalnym scopingiem. Niezbyt lubię magiczne rozwiązania :P. Więc to nie tyle twórcy języka poszli na łatwiznę, co ratują programistę przed jego błędami.
Tak samo jak nic nie stoi na przeszkodzie żeby int i; int j = i + 2; się kompilowało (i miałoby domyślną wartość zero). Ale twórcy woleli zabronić takiej konstrukcji.
Z punktu widzenia kompilatora, to czytelne nazewnictwo i podział na klasy też jest redundantny. Kompilator wie z jakiego rodzaju metodą czy zmienną ma do czynienia, ale czytający kod będzie musiał stracić czas na dowiedzenie się tego. this nie jest redundantne, bo przekazuje konkretną treść. Owszem, można metody rozróżniać za pomocą prefiksów, ale to się nazywa notacja węgierska i jest po prostu głupie.
this. to redundancja, a nadmiarowy podkreślnik nie?
Zostałam przekonana.
Do wołania metody wciąż bym nie użyła, a przynajmniej nie przychodzi mi do głowy sytuacja, w której miałoby to sens.
(Kurka wodna, ale czeka mnie refaktoringu...)
Ja klepię w Scali i praktycznie nie używam this. Zwykle użycie tego jest antywzorcem bądź jest co najmniej nieidiomatyczne. W Scali wywołania metod bezparametrowych i dostęp do pól są zunifikowane. Można zrobić coś takiego:
trait MójInterfejs {
def długość: Int // def służy do definiowania metod
}
class MojaImplementacja(parametr: Int) extends MójInterfejs {
val długość = parametr + 5 // val służy do definiowania stałych
}
Pole długość w klasie MojaImplementacja implementuje abstrakcyjną metodę długość z bazowego traita. Z powyższego wynika wprost iż próby rozróżniania na metody bezparametrowe i pola są bez sensu w Scali.
Istnieje natomiast konwencja według której metody bezparametrowe, które są czyste (nie zmieniają stanu) powinny nie mieć nawiasów w definicji, natomiast metody które coś zmieniają i zwracają Unit (odpowiednik Javowego void) powinny mieć puste nawiasy. Przykład:
class Abc {
private var x = 5
def mutuj(): Unit = x += 8
def oblicz: Int = x - 4
}
Rzadko kiedy jest problem z omyłkowym potraktowaniem defa jako vala czy vice versa.
A w sumie, to czemu używać akurat _ jako prefiksu? Nie lepiej $? Kod z dolarami zawsze będzie piękniejszy.
Bo na dolary to phpowcy mają wyłączność. Tam gdzie nie spojrzysz, wszędzie dolary
Ja zacząłem używać podkreślnika dla pól prywatnych w C# i muszę powiedzieć, że lepiej się pracuje gdy od razu widać, które zmienne to pola, a które lokalne. Piszcie co chcecie, ale ja nadal będę używać podkreślników. Nie używam natomiast this praktycznie wcale.
PS. To jest jeden z dwóch przypadków używania przeze mnie podkreślników w kodzie. Drugim są nazwy metod testowych
(public void my_test_method())
Sarrus napisał(a):
Ja zacząłem używać podkreślnika dla pól prywatnych w C# i muszę powiedzieć, że lepiej się pracuje gdy od razu widać, które zmienne to pola, a które lokalne.
Masz rację. A jeszcze lepiej, gdy widać, które pola są publiczne, które prywatne, a które statyczne, i jeszcze najlepiej od razu wiedzieć, jakie mają typy.
Mam taki pomysł - rozbudujmy trochę nasz ukochany prefiks, niech nie będzie tylko samotnym podkreślnikiem!
Zróbmy tak - jedna literka na lewo od podkreślnika niech określa zasięg zmiennej, np. w ten sposób: g - publiczna, m - prywatna, s - statyczna, a jedna na prawo jej typ, np.: i - int, s - string, b - bool.
No i teraz będziemy mieli np. taki zapis:
m_bCzyPrefiksySąFajne = true;
p_iOcenaFajnościWspaniałościPrefixów = 15002900;
s_sHasłoNaDzisiaj = "this to redundancja, ale prefiksy nie!!!!111oneoneone";
Piękne, nie? Nic tylko patentować.
msm napisał(a):
Bez przesady, nie można wyeliminować
thisbo this ma kilka zastosowań gdzie go się nie da zastąpić (przykładowo:void Asdf() { RegisterSomething(this); })
ok, przekazywanie this jako parametr czy deklarowanie indeksera to inny temat, chodzilo mi o uzywanie this do ujednoznacznienia skladowej.
prefixu 'this' uzywam praktycznie wylacznie w konstruktorach, equals itp gdzie kod jest prawie zawsze wygenerowany r#, imo zamiast generowac tyle linijek nudnego kodu platforma powinna pozwalac jakos zgrabnie to ominac.
koniecznosc uzywania this w metodach jako prefix lokalnych pol/metod w celu wskazania zakresu zwykle oznacza ze jest problem z nazewnictwem/odpowiedzialnoscia w danej klasie.
Prefiks to CZĘŚĆ NAZWY zmiennej. this NIE jest częścią tejże nazwy. this TO NIE JEST PREFIKS.
IDE0003 mówi, że "Name may be simplified".
SA1101 mówi: "The call must begin with the 'this.' prefix to indicate that the item is a member of the class."
Nie wiem komu mam wierzyć...
BTW, https://github.com/dotnet/corefx/blob/master/Documentation/coding-guidelines/coding-style.md -> punkt 4 mówi, żeby unikać this jeżeli nie jest konieczne. Ale jednocześnie też zaleca przedrostki , s oraz t_ ;-)
Dodatkowo widzę tu pewną niekonsekwencję. Wyobraźmy sobie, że mamy parametr metody albo zmienną lokalną o takiej samej nazwie jak pole klasy. Wtedy użyjemy this, bo inaczej się nie da. W pozostałych przypadkach bez this, bo redundancja.
Dla mnie to brak konsekwencji. Albo wszystko z this albo wszystko bez. Dobry kod powinien być czytelny nawet w notatniku, jeśli do tego potrzeba kolorowania składni z ide, to znaczy że to zły kod
Tokarz_ napisał(a):
Albo wszystko z this albo wszystko bez.
Albo zawsze jest else po if, albo nigdy. Bądźmy konsekwentni.
Zaczyna się rodzić programistyczny faszyzm.
Ja używam self:
class Foo {
self =>
def foo = ???
def bar = self.foo
}
:P
A tak bardziej serio, to zwykle nie używam jak nie muszę. Ale czasem przy pisaniu komparatorów np. kod ładnie wygląda jak się używa this i that na oznaczenie porównywanych obiektów.