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?
źródło
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.public abstractmetody w interfejsie.privatemetody w interfejsie nie mają sensu iabstractsą sugerowane.Odpowiedzi:
Cytowany tekst to:
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.
źródło
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.
źródło
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ć.
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).
źródło