Poleganie na domyślnej inicjalizacji pola - czy zły styl programowania? [Zamknięte]

20

Otrzymałem link do oficjalnej dokumentacji wyroczni: https://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html

gdzie jest powiedziane:

Wartości domyślne

Nie zawsze konieczne jest przypisanie wartości podczas deklarowania pola. Pola, które są zadeklarowane, ale nie zainicjowane, zostaną ustawione przez kompilator na rozsądną wartość domyślną. Ogólnie rzecz biorąc, ta wartość domyślna będzie wynosić zero lub zero, w zależności od typu danych. Jednak poleganie na takich wartościach domyślnych jest ogólnie uważane za zły styl programowania.

Chcę podkreślić tę część:

Jednak poleganie na takich wartościach domyślnych jest ogólnie uważane za zły styl programowania.

Ale, och, chłopcze, to, powiedziałbym, podstawowa część specyfikacji języka, wiedząc, że zmienne instancji mają wartości domyślne. Dlaczego, u licha, jest to zła praktyka programistyczna, jeśli jest szeroko stosowana nawet w kodzie źródłowym bibliotek Java SE?

Andremoniy
źródło
5
Huh Nigdy nie wiedziałem, że tam jest takie oświadczenie. Uważam, że poleganie na nich jest dobrą praktyką. private int count = 0;jest kodem, który nic nie robi, a kodem, który nic nie robi, jest bałagan. To jak importowanie klas z java.lang lub deklarowanie klasy za pomocą extends Object.
VGR
2
... lub posiadanie public abstractmetody w interfejsie.
mumpitz
1
co jest nie tak z publicznym streszczeniem?
John Keates,
1
Kawałek układanki może pochodzić z C ++. Jest to popularny język, a jego obsługa domyślnej inicjalizacji w stosunku do inicjalizacji zerowej jest ciągłym źródłem błędów. W C ++ oparcie się na wartościach domyślnych jest bardzo złym pomysłem we wszystkich przypadkach oprócz wyjątkowych. To mogło przeciekać kulturowo do Javy.
Cort Ammon,
@JohnKeates - Moja Java jest nieco zardzewiała, ale privatemetody w interfejsie nie mają sensu i abstractsą sugerowane.
Scott Smith

Odpowiedzi:

6

Cytowany tekst to:

„Poleganie na takich wartościach domyślnych jest jednak ogólnie uważane za zły styl programowania”.

Cynicznie: „powszechnie uważa się, że” często mówi, że autor nie próbował znaleźć wiarygodnego źródła prezentowanej wypowiedzi.

W takim przypadku twierdzenie jest wyraźnie wątpliwe. Dowody: 5 z 5 wybranych przewodników stylu Java NIE mówi nic o tym, czy powinieneś lub powinieneś polegać na wartościach domyślnych:

(Uwaga: moja metodologia próbkowania polegała na przejrzeniu pierwszych 5 różnych wyników wyszukiwania Google pod kątem „przewodnika po stylu Java”. Następnie przeszukałem każdy dokument pod kątem „domyślnego”. Nie jest to dogłębna analiza, ale służy to mojej racji. )


OK. Czy to naprawdę poprawia czytelność kodu Java?

To jest dyskusyjne.

Z jednej strony początkujący programista Java, który nie dowiedział się o domyślnej inicjalizacji, może być zaskoczony tym, skąd pochodzą zera lub zera. Ale jeśli zawracają sobie głowę szukaniem wyraźnej inicjalizacji i stwierdzeniem, że jej nie ma, powinno to wystarczyć, aby przeczytali samouczek lub książkę, aby dowiedzieć się o domyślnej inicjalizacji. (Miałbyś nadzieję!)

Z drugiej strony zwykle nie oczekujemy, że początkujący programiści Java utrzymają produkcyjne bazy kodu. Dla doświadczonego programisty Java nadmiarowa inicjalizacja nie poprawia czytelności. Jest to (w najlepszym wypadku) hałas.

Moim zdaniem jedyne, co można osiągnąć dzięki redundantnej inicjalizacji pola, to zasygnalizowanie przyszłemu czytelnikowi twojego kodu, że pomyślałeś o wartości początkowej. (Jak wyraził to @GhostCat, domyślna inicjalizacja nie komunikuje zamiaru.)

Ale odwrotnie, gdybym był tym czytelnikiem, niekoniecznie ufałbym myśleniu autora kodu. Zatem wartość tego „sygnału” również jest wątpliwa.


Co z niezawodnością?

W Javie nie robi to różnicy. JLS określa, że domyślne inicjalizacji ma nastąpić na polach. I odwrotnie, w przypadku zmiennych lokalnych błędem kompilacji jest próba użycia zmiennej, która nie została zdecydowanie zainicjowana.

Krótko mówiąc, zachowanie środowiska wykonawczego zmiennej, która nie została jawnie zainicjowana, jest całkowicie przewidywalne.

W przeciwieństwie do języków takich jak C lub C ++, w których zmiennych nie można zainicjować, zachowanie jest nieokreślone i może prowadzić do awarii i różnic w zachowaniu na różnych platformach. Argument dotyczący zawsze jawnej inicjalizacji zmiennych jest tutaj znacznie silniejszy.


Co z wydajnością?

To nie powinno mieć znaczenia. Kompilator JIT powinien być w stanie traktować nadmiarową inicjalizację i domyślną inicjalizację tak samo.

Stephen C.
źródło
19

Proste: poleganie na wartościach domyślnych nie komunikuje zamiaru.

Czy naprawdę chciałeś, aby to pole zaczynało się od 0, czy zapomniałeś przypisać wartość ?!

I oczywiście odwołanie zerowe to połowa z dwóch rzeczy, które musisz spełnić, aby uzyskać wyjątek zerowy.

Wreszcie użycie wartości domyślnych oznacza, że ​​masz pola niefunkcyjne. Które unikasz tam, gdzie to możliwe.

Jedynym kontrargumentem jest: po co zapisywać rzeczy, których nie musisz? Ale myślę, że wymienione wady trąby, że w ten sposób wyraźne przypisanie 0 do pola jest lepsze niż pozostawienie go kompilatorowi.

GhostCat pozdrawia Monikę C.
źródło
3
tj. re: brak komunikacji intencji - Co jeśli „Manny the opiekun” patrzy na twój kod i nie wie, jakie są domyślne wartości dla określonego typu danych. Zakłada, że ​​ma wartość 0, gdy jest naprawdę NULL, i to jest cały błąd w teście === (lub cokolwiek równoważnego sprawdzeniu równości dla wartości i typu jest w java, equals ()?). Godziny poszukiwań (dla niedoświadczonego programisty) mogą być wynikiem czegoś tak prostego. PS próbuje grać w adwokata diabła. Mówię, że używaj wartości domyślnych przez cały dzień (chociaż nigdy tego nie robię) i zachęcaj mądrzejszych ludzi (lub przynajmniej większą uwagę do szczegółów) do utrzymania kodu.
TCooper
@TCooper, kiedy opiekun Mannie tak mało wie o Javie, to nie ma biznesu, który mógłby dotykać prawdziwego kodu Java. Ale zgadzam się z podstawowym pojęciem. To utrudnia początkującym.
GhostCat pozdrawia Monikę C.
12

Dlaczego, u licha, jest to zła praktyka programowania

Pomysł polega na tym, że jeśli polegasz na wartości domyślnej, to nie jest od razu jasne dla każdego, kto czyta kod, jeśli celowo pozostawiłeś go jako wartość domyślną lub po prostu zapomniałeś go przypisać.

... jeśli jest szeroko stosowany nawet w kodzie źródłowym bibliotek Java SE?

Kod źródłowy Java nie jest tak naprawdę czymś, na czym powinieneś polegać jako przykład przykładowej praktyki kodowania. Istnieje wiele przypadków, w których takie zasady są naruszane (czasami celowo w celu drobnych ulepszeń wydajności, a czasem przypadkowo lub dlatego, że zaakceptowany styl zmieniał się przez lata).

Michael Berry
źródło
2
Prawdopodobnie ma rację, choć się z tym nie zgadzam.
VGR
3
@VGR O ile zgadzam się z twierdzeniem, że poleganie na wartościach domyślnych nie jest optymalne, z tego powodu ostrożnie sformułowałem je w neutralny sposób. Jakość kodu jest subiektywna i jestem w pełni świadomy, że nie jest to pogląd powszechnie przyjęty.
Michael Berry