Deklaracja podziału i przypisanie = Dobra praktyka?

Będąc zapalonym użytkownikiem NetBeans, ciągle dostaję sugestie, aby podzielić moje deklaracje zmiennych i przypisania, gdy wprowadzę nową zmienną. Jak super szybki przykład od szczytu głowy, weźmy tę linię Java:Deklaracja podziału i przypisanie = Dobra praktyka?

String someInput = JOptionPane.showInputDialog(null, "- Enter something: ");

kontra:

String someInput; 
someInput = JOptionPane.showInputDialog(null, "- Enter something: ");

NetBeans wydaje się preferować ten ostatni (nie wiem o innych IDE, chociaż). Chociaż wyraźnie działa on w obie strony, co byłoby uważane za "dobrą praktykę", jeśli w ogóle? Czy to tylko kwestia osobistych preferencji?

(Oczywiście podział dwóch oznacza dodatkowy wiersz, który mógłby właśnie połączone w jeden, ale to mija się z celem.)

Źródło

2013-04-11 Fiery Phoenix

+13

To mnie zastanawia, że każdy wolałby ten ostatni w ciągu pierwszych. – NPE

Hmm, może masz coś zabawnego stylu w NetBeans! –

Pierwsza opcja to "ekonomiczny" sposób na zainicjowanie obiektu. (Myślę, że) Druga z nich jest nieco bardziej czysta, ponieważ pozwala zgrupować deklarację zmiennej z zadania. Myślę, że z czysto estetycznego punktu widzenia, drugi jest bardziej pożądany, ale pierwszy jest bardziej pożądany pod względem prostoty. – Barranka

Nie ma powodu, aby podzielić się z deklaracji i przypisanie jeśli tylko będzie mieć je na kolejnych liniach. Rozdzieliłbym je, gdyby zadanie było warunkowe, lub gdyby wymagało przejścia w osobnym bloku kodu (jak próba/catch, lub jeśli przypisanie odbywa się w konstruktorze itp.).

Źródło

2013-04-11 16:22:49

Tak, to wyczyści to. Lepiej trzymać się tego, co ma sens dla ciebie, niż dla IDE! –

Nie sądzę, że to wielka sprawa. Wybierz styl, który ci się podoba i trzymaj się go przez cały czas (jeśli jesteś w zespole, to pomaga, jeśli wszyscy układają swój kod w podobny sposób).

Ja osobiście wolę inicjować moje zmienne bezpośrednio w momencie deklaracji. Z tego powodu wolałbym ten pierwszy niż ten drugi.

Źródło

2013-04-11 16:23:51 NPE

Powszechnie spotykany wzorzec, który powraca do wczesnego programowania statycznie pisanego, to zadeklarowanie wszystkich potrzebnych zmiennych u góry bloku, do którego mają być ograniczone, a następnie przypisanie do tych wartości później.

Powiedziawszy to, tak długo, jak jesteś w stanie jasno przekazać intencję swojego kodu ludziom, z którymi pracujesz, lub sobie w ciągu roku, nie powinno to mieć znaczenia.

Zmieńmy nasze tradycyjne podejście do budowy programów: Zamiast wyobrażając sobie, że nasz głównym zadaniem jest poinstruować komputer, co robić, niech nam koncentrat raczej na wyjaśnianiu ludziom co chcemy komputer do zrobienia. - Donald Knuth

Źródło

2013-04-11 16:24:50 jpredham

+1 Niezły cytat, dziękuję! – Barranka

+1 'declare; ogłosić; ogłosić; przydzielać; przydzielać; assign; 'jest prawdopodobnie stylem, który NetBeans próbuje wymusić, zamiast' deklarować; przydzielać; ogłosić; przydzielać; ogłosić; przypisz; '. –

Bardzo miły cytat, dzięki! –

Code Complete, który jest dobrze postrzegany przez większość społeczności programowania, sugeruje jej stronie 241, że w kwestii programowania obronnego można albo zainicjować każdej zmiennej, jak to jest zadeklarowana (Twoja pierwsza opcja) lub zainicjuj go blisko miejsca, w którym został po raz pierwszy użyty (twoja druga opcja).

Niemniej jednak książka sugeruje, że druga opcja jest lepsza, ponieważ jeśli skorzystasz z pierwszej opcji, zmienna może ulec zmianie między deklaracją a jej użyciem.

W twoim przypadku różnica między deklaracją a użyciem w drugim przypadku to pojedyncza linia. W związku z tym obawy książki nie mają zastosowania. Niemniej jednak, jego obawy są uzasadnione i może to być powodem, dla którego projektanci Netbeans zawarli tę wskazówkę (mimo że nadużywali jej).

Źródło

2013-04-11 16:29:18 rlinden

Wygląda na to, że niewłaściwie stosujesz się do porad książki. Strona, do której się odwołuje, stwierdza, że "Niektóre języki, w tym Visual Basic, nie obsługują inicjowania zmiennych, ponieważ są zadeklarowane", ale Java nie jest jednym z tych języków, więc nie ma to zastosowania. Książka stwierdza: "Idealnie, deklaruj _i określ każdą zmienną blisko miejsca, w którym została po raz pierwszy użyta ... W językach, które ją obsługują, takich jak C++ i Java, zmienne powinny być zadeklarowane i zdefiniowane blisko miejsca, w którym są po raz pierwszy używane." To nie jest ani jedna, ani żadna propozycja z Javą. – DavidS

Netbeans sugeruje to, ponieważ może przyspieszyć kodowanie, na przykład pod uwagę to zadanie

final String myString = "somevalue"

wtedy zdecydować, że faktycznie wartość zależy od jakiegoś boolean

final String myString; 
if(something) { 
    myString = "somevalue" 
} else { 
    myString = "someothervalue" 
}

Aby przekonwertować jednego z do możesz użyć podpowiedzi kodu do rozlania deklaracji i przypisania oraz szablonu if...else, aby wygenerować kod w kilku krokach.

Generalnie, jeśli przydziela się bezwarunkowo, nie ma powodu, aby dzielić deklarację i przydział.

Źródło

2013-04-11 16:31:12

Nie sądzę, że dzielenie deklaracji z przydziału na przejęcie użycia takiego przypadku (jeśli/else, try/catch, itp.) Jest tego warte, gdy uznasz, że wymaga to przepisania nazwy zmiennej. – Alexander

"Uczyńmy cały kod dłuższym i niepotrzebnie bardziej złożonym, abyśmy mogli ogolić niewielką ilość czasu z już szybkiego zadania poza szansą, że jest to pewnego dnia konieczne." Tak. – Alexander

@AlexanderMomchliov kod jest inny. Jeden jest bezpośrednim zadaniem, a drugi jest warunkowym zadaniem. Naprawdę nie rozumiem, jak twój komentarz pasuje. –

To była opcja dodana do NetBeans gdzieś pomiędzy 7.0 a 7.3. Jeśli ci się nie podoba to podpowiedź może być zmieniona przez odznaczenie: Narzędzia> Opcje> Edytor> Wskazówki> Sugestie> Deklarację podziału

Screenshot of NetBeans > Prefs > Hints > Suggestions > Split Declaration

Źródło

2013-04-11 17:52:09

Dla IntelliJ IDEA jest to plik - Ustawienia - Edytor - Intencje - Java - Deklaracja - Deklaracja Split. – RenniePet

Deklaracja podziału i przypisanie = Dobra praktyka?

Odpowiedz

Powiązane problemy