Wpis z mikrobloga

obj.getExamle() == Enum.TEST


@MyTearsAreBecomingASea: Bo jak się walniesz i zamiast obj.getExamle() == Enum.TEST napiszesz obj.getExamle() = Enum.TEST, to najprawdopodobniej dzisiaj dostaniesz warninga. Ale kiedyś tak nie było i ten warunek był zawsze ewaluowany jako true. No ale jak napiszesz Enum.TEST = obj.getExample() zamiast Enum.TEST == obj.getExample(), to zawsze dostaniesz error.
@MyTearsAreBecomingASea: Zanim dasz -1, sprawdź co konretnie się stanie, jeśli zrobisz obj.getExamle() = Enum.TEST zamiast obj.getExamle() == Enum.TEST. Bo może się okazać, że te stare pierdy mają rację.

Inna bajka, co jest konkretnie napisane w coding guidelines. Bo jeśli coding guidelines tego wprost nie zabraniają, to nie masz się o co przypieprzać. Fakt, że Twoim zdaniem kod jest nieczytelny, to tylko i wyłącznie Twoja opinia. A opinia jest jak dupa -
@MyTearsAreBecomingASea:

o chłopie, chłopie @groman43 ja myślałem, że ty jesteś fachowiec na tagu, a takie bzdury napisałeś...

Nie chodzi o to.

Chodzi o podstawy podstaw podstaw programowania i porównywania wartości, stosowania znaku "==" lub metody .equals()

Zasada ta mówi, że zawsze z lewej strony powinniśmy mieć wartości, które nie są null. Enum.Test nigdy nie jest nullem, natomiast obj.getExample() może być nullem. Z tego względu dobre praktyki nakazują Enum.Test dać po lewej
@KrolJulian: programiści Javy zawsze mają pod górkę - rozwiązują problemy niespotykane nigdzie indziej xD W dobrze zaprojektowanych językach jest jeden operator do przyrównywania. Ponadto equals w klasie bazowej to w ogóle straszna głupota bo przez to możesz niechcący napisać klasa1.equals(klasa2) co zawsze da fałsz, zamiast dostać błędem kompilacji.