Cześć,
Czy mógłby ktoś powiedzieć, co robi powyższa metoda? Co oznaczają te znaki zapytania i dwukropek.
0
8
Bardzo nie lubię jak ktoś wyłącza myślenie i wstawia ternary operator lub if else gdzieś, gdzie zwykłą logika boleanowska załatwia sprawę.
private boolean isRed(Node<K, V> node) {
return node != null && mode.isRed();
}
To jest o niebo bardziej czytelne.
offtopic:
@elo_elo_elo nigdy nie wstawiaj kodu (ani żadnego innego tekkstu) jako obrazek. Wklejaj teks zawsze jako tekst, składnie pokoloruje ci forum jeśli użyjesz ostatniej opcji z belki.
1
MarekR22 napisał(a):
Bardzo nie lubię jak ktoś wyłącza myślenie i wstawia ternary operator lub if else gdzieś, gdzie zwykłą logika boleanowska załatwia sprawę.
private boolean isRed(Node<K, V> node) { return node != null && mode.isRed(); }To jest o niebo bardziej czytelne.
offtopic:
@elo_elo_elo nigdy nie wstawiaj kodu (ani żadnego innego tekkstu) jako obrazek. Wklejaj teks zawsze jako tekst, składnie pokoloruje ci forum jeśli użyjesz ostatniej opcji z belki.
Mam wrażenie, że gdzieś zaginęła wiedza o wartościowaniu wyrażeń logicznych. tego "nie widać" jak się widzi kod "przez ramię", trzeba wziąć jakiś podkład teoretyczny - jak wiadomo, dla wielu nie jest pasjonujące ;)
Na gruncie tego przykładu ta wiedza jest ważna.
3
Mam wrażenie, że bardziej jednak problem polega na: jak to się stało, że node może być null.
Bym powiedział, że coś tu śmierdzi (i wcale nie proponuje stosowania Optional).
Oczywiście czasem są wyjątki, dziwne api, wymagania low level, ale najlepiej po prostu tego nulla nie mieć.
0
jarekr000000 napisał(a):
ale najlepiej po prostu tego nulla nie mieć.
W każdym projekcie którym lądowałem, zawsze prędzej czy później pojawia się != null. Musiałbym trafić na pisanie całkowicie niezależnego systemu od 0, żadnych integracji z już istniejącymi.
1
Korges napisał(a):
jarekr000000 napisał(a):
ale najlepiej po prostu tego nulla nie mieć.
W każdym projekcie którym lądowałem, zawsze prędzej czy później pojawia się != null. Musiałbym trafić na pisanie całkowicie niezależnego systemu od 0, żadnych integracji z już istniejącymi.
W każdym projekcie trafiają się ludzie, którzy nie cenią sobie dbałości o jakość i spójność logiczną kodu i zamiast poprawić null pointer exception przez ustalenie skąd się wzięło null wolą dopisać tego if-a.
0
jarekr000000 napisał(a):
Mam wrażenie, że bardziej jednak problem polega na: jak to się stało, że node może być null.
To wygląda na uczelniany przykład implementacji drzewa czerwono-czarnego i tam często w tej sposób jest tłumaczony algorytm.
1
MarekR22 napisał(a):
W każdym projekcie trafiają się ludzie, którzy nie cenią sobie dbałości o jakość i spójność logiczną kodu i zamiast poprawić null pointer exception przez ustalenie skąd się wzięło
nullwolą dopisać tegoif-a.
... kolejne (w skali cywilizacji) założenie Xxxxx jest OK, tylko ludzie.
Niestety, jest tak, że najbardziej wspaniali ludzie nie są ideałami, mają problemy, niewiedze, mają gorsze dni itd... Kombinowanie na zasadzie "liczenia na jakość ludzi" zawsze się zemści
0
https://dzone.com/articles/us[...]nal-correctly-is-not-optional — MarekR22 2020-10-29 19:30
Super artykuł.
Ja pokręcę jednak dłużej kijem w mrowisku
*
The purpose of Java 8Optionalis clearly defined by Brian Goetz, Java’s language architect:
Optional is intended to provide a limited mechanism for library method return types where there needed to be a clear way to represent “no result," and using null for such was overwhelmingly likely to cause errors.*
oraz
*Item 13: Do Not Declare Any Field of Type Optional
Do not use Optional in methods (including setters) or constructors arguments.
Remember thatOptional was not intended to be used for fields and it doesn't implementSerializable. TheOptionalclass is definitively not intended for use as a property of a Java Bean.
*
Na poziomie koderskim VAVRowki Option implementuje Serializable, ale to tylko szczegół zdradzający mocno inne zamiary, obejmujące pola (trwałe dane).
Optional jest bardziej "pokorny", nie usiłuje sygnalizować, że jednym ruchem ręki naprawia wszystkie błędy i zaniedbania Javy 1)
Mnie to bardziej przekonuje.
Co myślicie?
- inaczej mówiąc, nie da się *jednym ruchem ręki *naprawić zaniedbań odnośnie Nulli w danych.
0
AnyKtokolwiek napisał(a):
- inaczej mówiąc, nie da się *jednym ruchem ręki *naprawić zaniedbań odnośnie Nulli w danych.
Mnie się wydaje że żaden sposób na zastąpienie "problemu" nulla równoważnym mechanizmem nie będzie zadowalający.
Te wszystkie optionale to jest wynajdywanie nulla na nowo tak by nie nazywać tego nullem.
To tak jak singleton który funkcjonalnie jest zmienną globalną no ale nie nazywa się tak.
0
MarekR22 napisał(a):
private boolean isRed(Node<K, V> node) { return node != null && mode.isRed(); }To jest o niebo bardziej czytelne.
Jest w Javie coś podobnego do takiego zapisu w C#?
return node?.isRed() ?? false;
2
Burmistrz napisał(a):
MarekR22 napisał(a):
private boolean isRed(Node<K, V> node) { return node != null && mode.isRed(); }To jest o niebo bardziej czytelne.
Jest w Javie coś podobnego do takiego zapisu w C#?
return node?.isRed() ?? false;
groovy przeciera(ł) ścieżki, a nawet jeszcze ładniej
http://groovy-lang.org/operators.html#_elvis_operator
Trochę mi żal tego języka, zasługuje na wiele więcej niż tylko frameworki do buildu i testów.
2
Mnie się wydaje że żaden sposób na zastąpienie "problemu" nulla równoważnym mechanizmem nie będzie zadowalający.
Te wszystkie optionale to jest wynajdywanie nulla na nowo tak by nie nazywać tego nullem.
Nieprawda.
Jest zasadniczy problem z nullem, który rozwiązywany jest przez Option(al):
Dziura w systemie typów.
To, że w dowolnym miesjcu gdzie zwracany jest typ T może być podstawiony null to niestety dramat wielu języków (na pewno javy, scali, C++...)
Niszczy to local reasoning - bo nie wiesz czy ktoś przekazał T... czy może akurat miał zły dzień i wstawił w to miejsce null.
Więc albo wstawiasz null checka ... co może się skończyć tak, że połowa kodu to śmieci (nullchecki na rzeczy, które i tak nullami nie będą).
Albo nie wstawiasz null checka.. bo się dogadaliście, że nulli nie używacie, ale któregoś pięknogo dnia przychodzi jakiś spryciarz do zespołu robi refaktoring... i nullpointer ląduje na produkcji.
Rozwiązaniem na to jest konsekwentnie używanie Optionalla (w miejscach gdzie faktycznie nie ma wartości) + plugin do CI, który automatycznie wysyła wypowiedzenie po użyciu null przez commitującego.