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

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.

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.

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.

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.

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.

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.

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