Czy używacie krótkich nazw argumentów w krótkich lambdach?

Sytuacja, piszecie w swoim ulubionym języku programowania jednoliniową lambdę, czy uzywacie długich opisowych nazw argumentów czy jednak krótkich?
Czemu o to pytam? No bo w Scali jest domyślna nazwa na to _ więc taka lambda wyglada często .map(_.toString). W Kotlinie czy Groovim jest podobnie tylko domyślna nazwa to it, więc lambda wygląda .collect { it.toString() }. Ale jakoś w Javie programiści często chcą żeby użyć długiej nazwy bo przecież jnaczej nie będzie wiadomo o co chodzi i mam .map(veryImportantObject -> veryImportantObject.toString()). Czy to jest czytelniejsze niż .map(o -> o.toString) ? Przecież całość to i tak

veryImportantObjects.toStream()
  .map(veryImportantObject -> veryImportantObject.toString())
  .toList();

Jaka konwencja jest w innych językach? Pytanie dodatkowe: czy Java nie miałą wprowadzać domyślej nazwy jak groovy czyli it?

W Javie daję po prostu pierwszą literę nazwy obiektu. Jak ktoś czyta taki kod to i tak z kontekstu jest jasne, z czym ma do czynienia. Dopiero jak lambda ma więcej linijek to się bardziej rozpisuję.

Ale jakoś w Javie programiści często chcą żeby użyć długiej nazwy bo przecież jnaczej nie będzie wiadomo o co chodzi i mam bo w Javie od zawsze uczą, że długie nazwy są dobre. Jak w przypadku prawie każdej radykalnej zasady jest to błędne.

Co do konwencji to jest różnie. W Go jak i w C programiści lubią proste nazwy w stylu grp, x, buf, bo taka jest tradycja. W przypadku Javy mamy bardzoDługieNazwyAbstractFactory.

IMO jedyna słuszna zasada to długość nazwy uzależniona od kontekstu. Jak mamy pętlę for to używamy i, j, k a jak mamy jakieś globalne mutowalne pole to superNazwaKtóraWszystkoDokładnieOpisuje

Ja bym użył method Reference zamiast lambdy, a jak trzeba lambdę to krótką nazwę

a są jakieś ustalenia ogólne w firmie? bo może są

ja zazwyczaj w takim przypadku w c# mam i lub item

Jedyne krótkie nazwy na jakie pozwoliłbym sobie w programowaniu to i jako licznik pętli, albo x/y jeśli mówimy o koordynatach. W żadnym innym wypadku (również w lambdach) nie używam takich zmiennych.

Wyjątkiem mogą być konwencje, tak jak w Pythonie w bibliotece pandas się przyjęło że DataFrame to jest df, albo w React/Vue, przyjęło się że funkcja renderująca to h(). Wtedy to nie jest mój wybór, tylko stosuję się do konwencji, żeby nie zaciemniać kodu.

Ale pozostałe 99% przypadków, raczej używam jednego-dwóch słów na nazwę zmiennej.

KamilAdam napisał(a):

Ale jakoś w Javie programiści często chcą żeby użyć długiej nazwy bo przecież jnaczej nie będzie wiadomo o co chodzi i mam .map(veryImportantObject -> veryImportantObject.toString()). Czy to jest czytelniejsze niż .map(o -> o.toString) ? Przecież całość to i tak

veryImportantObjects.toStream()
  .map(veryImportantObject -> veryImportantObject.toString())
  .toList();

@KamilAdam Jeśli iteruję po kolekcji, i mam lambdę w .map()/.filter(), a kolekcja nazywa się "przymiotnik + rzeczownik", np "removed items" to z reguły nazwę argument w lambdzie samym tylko rzeczownikiem, np. item - żeby pokazać że ten argument jest elementem kolekcji.

Inne lambdy rządziłyby się pewnie innymi prawami.

1. Ustalcie sobie w zespole czy to lubicie
2. Jak dla mnie to może być o ile jest czytelnie (np. nie ma 3 roznych obiektow wokol zaczynajacych się od "i"), czyli wiem od razu o co chodzi i nie muszę marnować energii na domyślanie się co autor miał na myśli

KamilAdam napisał(a):

Jaka konwencja jest w innych językach?

W C# zazwyczaj używa się x, ale to nie jest jakaś ustalona konwencja.
Aczkolwiek ja często używam pierwszej litery nazwy klasy, ewentualnie pierwszych liter ze słów nazwy, jeśli w jednym wyrażeniu mam tych lambd wiele, a już na pewno jeśli są zagnieżdżone.

Ja szczerze w projektach (w Javie) nigdy się z czymś takim nie spotkałem
.map(veryImportantObject -> veryImportantObject.toString())
zawsze to było
.map(v -> v.toString())
lub
.map(vio -> vio.toString())

a teraz używamy method reference bo jakiś uberUberMenago zacząć psioczyć na sonary
.map(VeryImportantObject::toString)

Im krótszy zakres leksykalny tym bardziej pasuje krótsza nazwa.

Riddle napisał(a):

Jedyne krótkie nazwy na jakie pozwoliłbym sobie w programowaniu to i jako licznik pętli, albo x/y jeśli mówimy o koordynatach. W żadnym innym wypadku (również w lambdach) nie używam takich zmiennych.

Wyjątkiem mogą być konwencje, tak jak w Pythonie w bibliotece pandas się przyjęło że DataFrame to jest df, albo w React/Vue, przyjęło się że funkcja renderująca to h(). Wtedy to nie jest mój wybór, tylko stosuję się do konwencji, żeby nie zaciemniać kodu.

Ale pozostałe 99% przypadków, raczej używam jednego-dwóch słów na nazwę zmiennej.

To częste podejscie. Spotkałem się kiedyś z argumentacją, że przecież miejsca w repo starczy, nie musimy ograniczać rozmiaru pliku w bajtach, więc wielowyrazowe nazwy należy używać. Kompilator też to wytrzyma.

Moim zdaniem to jest kompletnie chybione podejście. Nadużywanie długich nazw jest złe nie dlatego, że brakuje miejsca w repo, albo ze zabraknie ramu przy kompilacji, tylko dlatego, że takie nazwy są nieczytelne.

f - WTF, co to jest f?

Foo - OK, wystarczył jeden rzut oka, by mój mózg od razu wychwycił i zinterpretował wszystkie 3 literki

FooBarWithFizzBuzzFromBlahBlahYaddaThatQuacksAndBarks - no niejstety mam tu zatrzymanie. Przetworzenie tego łąńcuszka zajmuje mi ładne sekundy. Ta nazwa wcale nie jest czytelniejsza.

A jeśli obok mamy dodatkowo jakieś

FizzBuzzWithoutFooBarFromBlahBlahYaddaThatQuacksButDoesNotBark - to już w ogóle dramat, nie umiem rozróżnić obu na pierwszy rzut oka.

Która z tych nazw będzie odpowiednia, zależy od kontekstu. W lambdzie f może wystarczyć. W polu globalnym może rzeczywiście trzeba pisać elaborat na wiele wyrazów.

Ale NIE(!) jest prawdą, że im dłuższa i bardziej opisowa nazwa, tym czytelniejsza. Conf zamiast Configuration często bywa czytelniejsze. IMO należy stosować nazwy najkrótsze możliwe, które jednak nie budzą wątpliwości odnoście znaczenia zmiennej.

YetAnohterone napisał(a):

IMO należy stosować nazwy najkrótsze możliwe, które jednak nie budzą wątpliwości odnoście znaczenia zmiennej.

Zgadzam się że krótka, opisowa nazwa jest idealnym celem.

Ale lepsza jest długa opisowa, niż krótka nic nie mówiąca. Jeśli ktoś ma pomysł jak ją skrócić, zachowując pełnię znaczenia - super. Jeśli nie, IMO powinien zostawić długą.

Riddle napisał(a):

Ale lepsza jest długa opisowa, niż krótka nic nie mówiąca. Jeśli ktoś ma pomysł jak ją skrócić, zachowując pełnię znaczenia - super. Jeśli nie, IMO powinien zostawić długą.

Często znaczenie wynika z kontekstu.

Np w lambdach:

var furColors = pets.Select(p => p.FurColor);

wiadomo, czym jest p.

Można się uprzeć, że trzeba napisać koniecznie pet, ale to będzie IMO gorzej, bo pet może się mylić z pets.

W Scali to nawet bedzie pets.map(_.furColor) bo kontekst jest oczywisty

W C# używam x pomimo że wiem, że powinno się (dobra praktyka) nawiązać do nazwy klasy <shame> :(

Używam x, jak nikt się nie czepia (w zależności od miejsca trafają się upierdliwcy co jak czytają pets.Select(x => x.FurColor) zdążą zapomnieć co jest w kolekcji i trzeba to im podawać wprost).

Tak na serio, to dowolna nazwa jest dobra, tak długo jak ludzie pracujący nad kodem rozumieją co tam siedzi.

Zrób eksperyment: sprawdź ile razy ktoś poświęca np. 10/20/50 sekund na wykminienie co siedzi w zmiennej? Jeśli dużo - to zmień nawyki. Jeśli mało, to widocznie taki sposób dla Ciebie działa i nie trzeba nic zmieniać.

Drzewowcy: - używaj długich, opisowych nazw.
Również drzewowcy:

public interface Table<
    R extends @Nullable Object, C extends @Nullable Object, V extends @Nullable Object> {

ale tak naprawdę to nie ma nic zdrożnego - to zasada znana już w hasklu - im bardziej generyczny argument tym krótsza nazwa (bo mniej można o nim powiedzieć).

Miang napisał(a):

a są jakieś ustalenia ogólne w firmie? bo może są

Uciekałbym z takiej firmy jaknajdalej.

Riddle napisał(a):

Miang napisał(a):

a są jakieś ustalenia ogólne w firmie? bo może są

Uciekałbym z takiej firmy jaknajdalej.

Yep, reguły maksymalnie na poziomie teamu odpowiedzialnego za akceptację PRów dla aplikacji.
I to tylko dlatego że nie chcę się za każdym razem spierać z developerem X dlaczego są krótkie nazwy zmiennych z developerem Y dlaczego używam krótkich a nie jednoliterowych. W ramach tej samej zmiany.
Ale reguły nie w postaci wyrytej na kamieniu, tylko wypracowanej jako dobry zwyczaj którego wystarczająca dokumentacją jest kod projektu.
Czyli wchodzę w mature projekt, widzę że enterprise Java mocno to użyję długich nazw dla utrzymania konwencji żeby główny developer zawału nie dostał.
Wejdę w nowy serwis w Kotlinie, będę polewał keczupem tak jak młode wilki zaplanowały.

opiszon napisał(a):

Riddle napisał(a):

Miang napisał(a):

a są jakieś ustalenia ogólne w firmie? bo może są

Uciekałbym z takiej firmy jaknajdalej.

Yep, reguły maksymalnie na poziomie teamu odpowiedzialnego za akceptację PRów dla aplikacji.
I to tylko dlatego że nie chcę się za każdym razem spierać z developerem X dlaczego są krótkie nazwy zmiennych z developerem Y dlaczego używam krótkich a nie jednoliterowych. W ramach tej samej zmiany.
Ale reguły nie w postaci wyrytej na kamieniu, tylko wypracowanej jako dobry zwyczaj którego wystarczająca dokumentacją jest kod projektu.
Czyli wchodzę w mature projekt, widzę że enterprise Java mocno to użyję długich nazw dla utrzymania konwencji żeby główny developer zawału nie dostał.
Wejdę w nowy serwis w Kotlinie, będę polewał keczupem tak jak młode wilki zaplanowały.

Te drugie reguły o których mówisz, moim zdaniem też są słabe.

Są lepsze sposoby na pogodzenie dwóch stylów pracy niż takie reguły.

Zapewne.
Ale świat jest jaki jest i z dwojga złego wolę taki kontrakt niż code style sprzed 20 lat utworzony przed architekta który juz wtedy był w wieku przedemerytalnym i ciągle pilnuje dokumentu jakby to był magiczny grimuar.

Inna sprawa że nikt się do tego dokumentu nie stosuje ;-)

opiszon napisał(a):

Zapewne.
Ale świat jest jaki jest i z dwojga złego wolę taki kontrakt niż code style sprzed 20 lat utworzony przed architekta który juz wtedy był w wieku przedemerytalnym i ciągle pilnuje dokumentu jakby to był magiczny grimuar.

Inna sprawa że nikt się do tego dokumentu nie stosuje ;-)

Ale po co takie zasady? One nikomu nie pomagają, a są dodatkową rzeczą do pamiętania.

Magiczny grimuar zamknięty w wieży z kości słoniowej architekta (zgodzę się że) czy konwencja w postaci istniejącego kodu?

Bo tego drugiego nie muszę pamiętać - to się samo czyta w większości przypadków a pamięć jest tak skonstruowana że jakiekolwiek ustalenia z resztą zespołu same mi się przypomną. Tak samo jak do dobrze napisanego kodu nie potrzeba komentarzy, wiec każdy kod z komentarzami idzie do poprawy w PR.

Tak, jest jeden sens żeby mały team miał spisane zasady (choć nigdy się z tym nie spotkałem) - jak przychodzi nowy dev i dajesz mu do zapoznania się żeby uniknąć trywialnych komentarzy w PR.
Natomiast dopóki firma nie zwolni na raz wszystkich developerów supportujacych projekt, to brak takiego dokumentu nie jest specjalnie problematyczny ;-)

Tak, wiem, pracuję/pracowałem w patośrodowiskach. Ale zarabiają sporo kasy, na chwałę udziałowców i pracowników.

opiszon napisał(a):

Magiczny grimuar zamknięty w wieży z kości słoniowej architekta (zgodzę się że) czy konwencja w postaci istniejącego kodu?

Strzelaj dalej.

Są lepsze sposoby niż te cztery które wymieniłeś.

Nie musze. Nie mam misji.

opiszon napisał(a):

Nie musze. Nie mam misji.

Jednym z takich sposobów to jest wypracowanie w zespole zaufania i wzajemnego szacunku z ludźmi którymi pracujesz, w taki sposób że pracujecie razem nie wchodząc sobie w drogę. Jeśli jesteś w stanie empatyzować z członkami zespołu, to jesteś bardziej skłonny widzieć ich perspektywę i pracować z nimi, nawet jak mają inne coding-styles. Wtedy takie drobnostki przestają mieć znaczenie, a zyskuje kooperacja, wspólne pomysły, etc.

Produktywność i jakość kodu też wtedy wzrasta, dużo bardziej niż wtedy gdy manago wymusi jakieś sztuczne zasady.

No i bardzo dobre podejście. Ale zawsze znajdzie się ktoś kto ci będzie PRy poprawiał ;-)

Choćby linter.

Btw. Nie wspominałem nigdzie o tym że manago wymusza zasady.
Właściciel aplikacji to nie manago tylko główny programista który jest za daną apkę odpowiedzialny (jeżeli w firmie istnieje coś takiego, a potrafi). Reszta zakładała samo dogadywanie się zespołu.
Jeżeli zespół dogada się tak że nie komentuje stylu - I'm fine.

opiszon napisał(a):

No i bardzo dobre podejście. Ale zawsze znajdzie się ktoś kto ci będzie PRy poprawiał ;-)
Choćby linter.

Btw. Nie wspominałem nigdzie o tym że manago wymusza zasady.
Właściciel aplikacji to nie manago tylko główny programista który jest za daną apkę odpowiedzialny (jeżeli w firmie istnieje coś takiego, a potrafi). Reszta zakładała samo dogadywanie się zespołu.
Jeżeli zespół dogada się tak że nie komentuje stylu - I'm fine.

Szczerze mówiąc, ani linter, ani "główny programista" nie brzmią jak dobre symptomy. To mi wygląda jak brak zaufania w zespole.

opiszon napisał(a):

No i bardzo dobre podejście. Ale zawsze znajdzie się ktoś kto ci będzie PRy poprawiał ;-)

Da się to rozwiązać prościej niż myślisz.

Jest gość, którego nie lubisz i on nie lubi Ciebie, i ciągle Ci rzuca komentarze pod PR. Co warto zrobić? Wziąć go na lunch, pogadać, zbliżyć dystans, spytać o jego perspektywe, co go boli w projekcie, znaleźć wspólne strony. Po pewnym czasie będziecie w stanie ze sobą pracować normalnie. Raz na jakiś czas (10%) trafisz na kogoś z kim po prostu nie jesteś w stanie się dogadać, nie pasujące osobowości - wtedy należałoby rozejść się do osobnych zespołów, albo znaleźć sposób żeby nie musieć razem pracować.