Ostatnio odkryłem radość z funkcji „Zapisz działania” w środowisku Eclipse IDE. Mogę zmusić go do przeformatowania kodu, wstawienia brakujących @Override
adnotacji i zrobienia kilku fajnych rzeczy, takich jak usuwanie niepotrzebnych nawiasów w wyrażeniach lub umieszczanie final
słowa kluczowego wszędzie za każdym razem, gdy kliknę ctrl + S
. Aktywowałem niektóre z tych wyzwalaczy i, chłopcze, to bardzo pomaga!
Okazało się, że wiele z tych wyzwalaczy działa jak szybkie sprawdzenie poprawności mojego kodu.
- Zamierzałem zastąpić metodę, ale adnotacja nie pojawiła się po uderzeniu
ctrl + s
? - być może gdzieś schrzaniłem typy parametrów!
- Niektóre nawiasy zostały usunięte z kodu podczas zapisywania? - może to wyrażenie logiczne jest zbyt trudne dla programisty, aby szybko się z nim obchodzić. W przeciwnym razie dlaczego miałbym dodawać te nawiasy w pierwszej kolejności?
- Ten parametr lub zmienna lokalna nie jest
final
. Czy musi zmienić swoją wartość?
Okazało się, że im mniej zmiennych, tym mniej problemów mam w czasie debugowania. Ile razy śledziłeś wartość jakiejś zmiennej tylko po to, by stwierdzić, że zmienia się ona jakoś powiedzmy od 5 do 7? „Jak do cholery może być ?!” zadajesz sobie pytanie i spędzasz kolejne kilka godzin wchodząc i wychodząc z niezliczonych metod, aby dowiedzieć się, że popełniłeś błąd w swojej logice. Aby to naprawić, musisz dodać jeszcze jedną flagę, kilka warunków i ostrożnie zmienić niektóre wartości tu i tam.
Och, nienawidzę debugowania! Za każdym razem, gdy uruchamiam debuger, mam wrażenie, że mój czas się kończy i rozpaczliwie potrzebuję tego czasu, aby spełnić przynajmniej niektóre z moich marzeń z dzieciństwa! Do diabła z debugowaniem! final
oznacza koniec tajemniczych zmian wartości. Więcejfinal
s => mniej wątłych części w moim kodzie => mniej błędów => więcej czasu na robienie dobrych rzeczy!
Jeśli chodzi o final
zajęcia i metody, nie obchodzi mnie to. Uwielbiam polimorfizm. Polimorfizm oznacza ponowne użycie oznacza mniej kodu oznacza mniej błędów. JVM i tak wykonuje całkiem dobrą robotę z dewitualizacją i wprowadzaniem metod, więc nie widzę wartości w zabijaniu możliwości ponownego użycia kodu dla nieoczekiwanych korzyści wydajnościowych.
Widzenie wszystkich tych final
znaków w kodzie na początku trochę rozprasza i wymaga czasu, aby się przyzwyczaić. Niektórzy z moich kolegów z zespołu wciąż są bardzo zaskoczeni, widząc tak wiele final
słów kluczowych. Żałuję, że nie było w IDE ustawienia dla specjalnego kolorowania składni. Z przyjemnością przestawię go na odcień szarości (np. Adnotacje), aby nie rozpraszały się podczas czytania kodu. Eclipse ma obecnie osobny kolor dla return
i wszystkich innych słów kluczowych, ale nie dla final
.
final
pól ma taką samą semantykę jak pisanievolatile
pola, a następnie czytanie ich później musi mieć zmienną semantykę odczytu, to nie zawsze to, czego chcesz