Jaka jest konwencja dla nazw zmiennych w wyrażeniach lambda?

Question

widzę wiele przykładów, gdzie na przykład

int sum = widgets.stream() 
        .filter(w -> w.getColor() == RED) 
        .mapToInt(w -> w.getWeight()) 
        .sum(); 

możemy wykorzystać dowolną variableName w tych wyrażeń lambda?

Uważam, że nazwy zmiennych mają konwencje i dobrze jest używać nazw własnych dla czytelności.

Na przykład, jeśli używam w jako Widget w pre-java8, kod zostanie odrzucony jako nieczytelny. Co się zmieniło wraz z nadejściem java 8?

for(Widget w : widgets) 
    { 
     if(w.getColor() == RED) { 
      sum += w.getWeight(); 
     } 
    } 

Dlaczego nie może być napisany kod tak:

int sum = widgets.stream() 
        .filter(widget -> widget.getColor() == RED) 
        .mapToInt(widget -> widget.getWeight()) 
        .sum(); 

Może powyższy kod robi coś prosto do przodu, a jedynie na widget na liście widżetów. Więc coś więcej:

Który jest lepiej czytelny:

return requestHolder.getRequests() 
         .stream() 
         .map(request -> request.getErrorHolder()) 
         .flatMap(errorData -> errorData.getErrors().stream()) 
         .collect(toList()); 

lub

return requestHolder.getRequests() 
         .stream() 
         .map(t -> t.getErrorHolder()) 
         .flatMap(r -> r.getErrors().stream()) 
         .collect(toList()); 

Może ja czegoś brakuje. Czy możesz wytłumaczyć?

Answer 1

Konwencja milcząca to: nazwij swoje zmienne, aby kod był przyjemny i czytelny.

Moim zdaniem, bardzo krótka nazwa lub fałszywa nazwa jest preferowana, gdy zakres zmiennej jest ograniczony. Dzięki temu kod staje się bardziej czytelny, lżejszy, a także wskazuje, że funkcja zmiennej jest ograniczona.

Jawne nazwy mają być preferowane, gdy zmienna jest szeroko stosowana w kodzie i chcesz uniknąć pomyłki z innymi zmiennymi.

for(int i = 0 ; i < max ; ++i) { 
    int myExplicitVar = myArray[i]; 
    // rest of the code using myExplicitVar several times 
} 

Dla lambda, zakres zmiennej jest zazwyczaj bardzo ograniczona i łatwiej czytać, gdy nazwa jest krótka więc tylko ważnych części kodu pozostaje, który był punktem wyrażeń lambda na pierwszym miejscu.

W waszych przykładach znajduję krótkie nazwy bardziej prosto do punktu.

Krótka nazwa zmiennej sprawia, że ​​kod jest mniej rozdęty, ale może prowadzić do nieporozumień w bogatym kontekście.

Answer 2

Cóż, używam Java 8 przez jakiś czas, i rzeczywiście stwierdziłem, że częściej używam dłuższych nazw. Moje podejście to prosta zasada: lubię krótkie imię lub nie.

I zwykle na krótkich nazw jak í lub y jeśli jest oczywiste, co się dzieje wewnątrz strumienia. Jeśli przetwarzasz strumień widżetów i wykonujesz operacje 4-6, pisanie widżetu za każdym razem jest irytujące i linie zaczynają wyglądać tak samo po kilku operacjach. Tak więc dla strumienia tych samych rzeczy, z kontekstu, z którego łatwo wiem, nad czym pracuję, czasami przechodzę do krótkich zmiennych.To samo, co w przypadku iteratorów pętli, w których każdy używa i, a nie indeksu .

Z drugiej strony, jeśli robię wiele przetwarzania, a zwłaszcza jeśli trzeba mapować coś, chciałbym dać opisowych nazw, idąc nawet do skrajności jak widget, filteredWidget, widgetHeight etc.

Co do popularnej notacji w Internecie, pamiętaj, że wiele osób próbuje promować nową składnię języka Java. Fajnie, że może być krótko, więc starają się wziąć go tak daleko, jak to możliwe. W Javalandzie zawsze musieliśmy dużo pisać i domyślam się, że ludzie przesadzają z tym, że możemy pisać mniej. Poszukaj przykładów na Venkat S. mówi o groovy lub .js od 2 lat wstecz, często nie odkrył, jak ważne jest to, że nie musi wpisywać średnika na końcu linii. Tak sądzę, jak działa nasz mózg.