Jakie są zalety poprzedzania nazw parametrów funkcji p *?

22

Często widzę projekty (w projektach Java i zespołach używających Eclipse), które poprzedzają parametry funkcji p.

Na przykład

public void filter (Result pResult) ...

Osobiście nie widzę w tym żadnej korzyści, ale chciałbym wiedzieć, jakie jest uzasadnienie. Najlepsze wytłumaczenie, jakie do tej pory słyszałem, to rozróżnienie nazw identycznych nazwanych pól. Mam problemy z tym wyjaśnieniem, ale rozumiem o co chodzi.

oschrenk
źródło

Odpowiedzi:

34

Praktyki dodawania znaczących prefiksów do symboli, takich jak dobrze nagłośniona notacja węgierska , sięgają czasów, gdy IDE nie istniały lub były zbyt prymitywne. Dziś, gdy znalezienie punktu deklaracji jest kliknięciem myszy, nie ma sensu zepsuć najcenniejszej części nazwy, jej pierwszych kilku liter, przypisując wspólny przedrostek.

dasblinkenlight
źródło
10
Systemowa notacja węgierska to straszna praktyka, której należy unikać. Z drugiej strony niektóre aplikacje węgierskiej notacji mogą być przydatne (na przykład w celu zapobiegania niewłaściwemu wykorzystaniu danych wprowadzanych przez użytkowników).
Casey Kuball,
7
@Darthfett: Nawet tego rodzaju węgierski zapis wydaje się próbować zaimplementować ręczny system ad-hoc bezpośrednio w nazwach zmiennych. Wystarczy użyć dobrego, statycznie wpisanego języka i mieć system prawdziwego typu, który automatycznie śledzi takie rzeczy dla Ciebie!
Tikhon Jelvis,
1
@WyattBarnett Systems Węgierski nie daje programistom żadnych użytecznych informacji o nowoczesnych IDE. Aplikacje węgierskie mogą zmniejszyć bóle głowy w recenzjach kodu, jeśli są odpowiednio egzekwowane.
Casey Kuball,
2
@ TikhonJelvis Nie wszystkie języki obsługują silnie wymuszone typy typef (np. C ++ typdef ). W przypadku języków, które go obsługują, masz całkowitą rację.
Casey Kuball,
4
@Darthfett: W C / C ++ możesz po prostu owinąć go w struct/ unionjednym elementem.
Maciej Piechotka,
9

Jak podejrzewasz, ma to na celu uniknięcie kolizji nazw między nazwą parametru a nazwami elementów członkowskich lub zmiennych lokalnych. Zmienne składowe czasami otrzymują prefiks z tego samego powodu (np m_result.). Osobiście wolę po prostu używać thisprefiksu dla zmiennych składowych, jeśli występuje kolizja nazwy. Jest wbudowany w język i wszyscy już wiedzą, co to znaczy.

Bill jaszczurka
źródło
Tak robię. Nieużywanie przedrostka pomaga również w Eclipse podczas wywoływania metody. Jeśli zbudowałeś drzewo obiektów i nazwałeś zmienne, takie jak nazwy parametrów metody, którą chcesz wywołać, działa to jak urok, ale jeśli nazwy parametrów mają prefiks, to nie działa.
oschrenk
5

Używam przedrostka parametru tylko wtedy, gdy parametr ma być przypisany do zmiennej składowej, takiej jak konstruktor lub setter.

Paint (newColor) {
  color = newColor;
}

Dla mnie uważam, że użycie innej nazwy zmiennej jest bardziej oślepiające niż użycie przedrostka „ten”.

W innych sytuacjach unikam używania parametru, który można łatwo pomylić ze zmienną składową.

Jeśli metoda lub klasa jest tak duża, że ​​trudno jest powiedzieć, co oznaczają zmienne, prawdziwym rozwiązaniem jest rozbicie jej na mniejsze metody / klasy. Używanie przedrostków to rozwiązanie wspomagające zespół, które rozwiązuje podstawowy problem.

Aaron Kurtzhals
źródło
Osobiście wolę w tym przypadku skrócić nazwę parametru (np Paint (clr) { color = clr; }.). ... Zwykle nie ma wieloznaczności, chociaż color -> clrw szczególności może być wyjątkiem.
Justin Time - Przywróć Monikę
1

Jeśli ustalisz standard, aby używać „p” jako prefiksu z nazwą każdego parametru metody, możesz łatwo rozpoznać parametry metody w pozostałej części treści metody.

Oszczędza Twój czas, aby znaleźć parametry metody. Możesz łatwo debugować kod.

Satish Pandey
źródło
1
Jeśli nie jesteś w stanie powiedzieć, co jest parametrem, a co nie - Twoja metoda jest prawdopodobnie źle napisana. Może jest za długi lub użyć zbyt wielu zmiennych nieustrukturyzowanych? Tak czy inaczej wydaje się, że jest to inny problem rozwiązany przez dodanie niepotrzebnych prefiksów.
jakubiszon
1

Krótko - ta praktyka utrudnia czytanie kodu.

Długo - będę argumentować, że jest to zła praktyka stosowana tylko do wspierania innych złych praktyk. Przeanalizujmy kilka powodów, dla których użycie takich prefiksów może być pomocne:

  • Unikanie kolizji w nazwach zmiennych

    • Czy nazwy parametrów dokładnie wyrażają parametry? Jeśli masz parametr i pole klasy, które są „dokładnie takie same”, nie potrzebujesz parametru.
    • W takim przypadku sensowne jest stosowanie tylko prefiksów dla konstruktorów klas, takich jak nowy * prefiks opisany w odpowiedzi Aarona. Może być również przydatny w metodach ustawiania, np

    public void setHeight(int newHeight) { this.height = newHeight; }

  • Metody przyjmują wiele parametrów, deklarują wiele zmiennych i możemy łatwo zapomnieć, który z nich jest parametrem.

    • Jak opisano powyżej - problem polega na liczbie zmiennych.
    • Program prawdopodobnie nie jest dobrze zorganizowany. Sprawdź, czy wszystkie zmienne są „niezależne” - być może powinny być zorganizowane w struktury lub klasy. Być może całe obliczenia lub proces powinny być zapakowane w osobną klasę tylko po to, aby operować taką liczbą zmiennych.
    • Nawet jeśli potrzebujesz takiej liczby zmiennych - powinny one używać znaczących nazw, a prefiks stoi między tobą a znaczącą częścią.
  • Metody są bardzo długie i musisz używać prefiksów, aby śledzić, co jest param.
    • Problem polega na długości metod - jeśli program jest napisany dobrze, zawsze powinieneś zobaczyć nagłówek metody i cały jej korpus na jednym ekranie.
    • Spróbuj podzielić metodę na mniejsze bloki.

Z wyjątkiem niektórych szczególnych przypadków dodawanie przedrostków parametrów pomaga jedynie w objawach i nie rozwiązuje rzeczywistych problemów.

jakubiszon
źródło
0

Jestem fanem iParam dla parametrów wejściowych i oParam dla parametrów wyjściowych. Powiedziałbym cParam dla zmiany, ale to nie do przyjęcia

Paweł
źródło
2
Czy możesz wyjaśnić, dlaczego jesteś fanem tego prefiksu, co zyskujesz, korzystając z niego?
Peter