Stosowanie podkreśleń w zmiennych Java i nazwach metod [zamknięte]


83

Nawet w dzisiejszych czasach często widzę podkreślenia w zmiennych i metodach Java, przykładem są zmienne składowe (takie jak „m_count” lub „_count”). O ile pamiętam, używanie podkreślenia w takich przypadkach jest przez Sun określane jako zły styl.

Jedynym miejscem, w którym powinny być używane, są stałe (jak w "public final static int IS_OKAY = 1;"), ponieważ wszystkie stałe powinny być pisane dużymi literami, a nie wielbłądami. Tutaj podkreślenie powinno sprawić, że kod będzie bardziej czytelny.

Czy uważasz, że używanie podkreśleń w Javie to zły styl? Jeśli tak (lub nie), dlaczego?

Odpowiedzi:


146

Jeśli nie masz teraz kodu, który go używa, sugerowałbym kontynuację. Jeśli Twój kod go używa, kontynuuj.

Największą zaletą stylu kodowania jest spójność . Jeśli nie masz nic, z czym mógłbyś być spójny, wtedy zalecenia dostawcy języka są prawdopodobnie dobrym miejscem do rozpoczęcia.


3
Używamy konwencji kodowania bez użycia znaków podkreślenia. W każdym razie, patrząc na frameworki i starszy kod, często widziałem podkreślenia. Na pytanie, że spójność rządzi konwencją, należy oczywiście odpowiedzieć za konsekwencję, ale nie o tym, o czym myślałem, zadając to pytanie.
Georgi

1
Dalsze używanie znaku „_” byłoby złą praktyką. Ten sposób pracy wiąże się z dodatkowymi kosztami utrzymania i musiałbyś poinformować o tych wyjątkowych konwencjach każdego nowego programistę, który dołącza do zespołu.
Halil

1
jest to podobne do nazewnictwa interfejsów w ten sposób: ReadableInterface- absolutnie zbędne. W nowoczesnych IDE nie musisz określać typu zmiennej ani jej zakresu - kolorowanie i szybkie przeskakiwanie wykonują całą pracę za Ciebie. Więc IMO to zły styl, ponieważ wpisujesz zbędne znaki i zmuszasz ludzi do czytania / utrzymywania go.
kiedysktos

122
sunDoesNotRecommendUnderscoresBecauseJavaVariableAndFunctionNamesTendToBeLongEnoughAsItIs ();

as_others_have_said_consistency_is_the_important_thing_here_so_chose_cokolwiek_you_think_is_more_readable ();

Na pytanie, że spójność rządzi konwencją, należy oczywiście odpowiedzieć za spójność, ale nie o to, o czym myślałem, zadając to pytanie. Zresztą czasami powinieneś zostawić stare ślady, co?
Georgi

2
Jeśli „sprzeczna” konwencja nazewnictwa jest już używana, myślę, że zależy to od ilości kodu, o którym mówimy. Nie polecałbym przepisywania tysięcy linii kodu tylko po to, aby przejść ze starej konwencji do nowej konwencji, biorąc pod uwagę, że stara konwencja jest używana konsekwentnie.
Anders Sandvig,

LOL! To powiedziawszy, kiedy kod zostanie wklejony w edytorach, które mają funkcję sprawdzania pisowni, słowa „błędnie napisane” są podkreślane, zasłaniając w ten sposób podkreślenie. To dobry powód, aby nie używać podkreśleń. Ponadto obudowa Camela jest krótsza. Wreszcie, klawisz Shift jest łatwiejszy w użyciu na literach niż w górnym rzędzie (tj. Kreska shift „-”).
Tihamer

@Tihamer Inni twierdzą, że snake_caseformularz jest łatwiejszy do odczytania. Szczególnie w przypadku krótkich słów (1-2 litery) zdecydowanie argumentowałbym, że tak jest. Jeśli chodzi o „trudne do wpisania”, wpisanie słowa z użyciem lotsOfMixedCaseWithinIt też nie jest zbyt wygodne. Opowiadałbym się za tym, że to kwestia tego, do czego jesteś przyzwyczajony. Jednak w Javie mówię „użyj zwykłej formy” zgodnie z zaleceniami JLS / etc. W Ruby / Python / C użyj przypadku węża. I tak dalej ...
Per Lundberg,

37

Zasady:

  1. Rób to, co robi edytowany kod
  2. Jeśli nr 1 nie ma zastosowania, użyj camelCase, bez podkreślenia

31

Nie sądzę, aby używanie _ lub m_ do wskazywania zmiennych składowych było złe w Javie lub jakimkolwiek innym języku. Moim zdaniem poprawia czytelność kodu, ponieważ pozwala spojrzeć na fragment kodu i szybko zidentyfikować wszystkie zmienne składowe z lokalnych.

Można to również osiągnąć, zmuszając użytkowników do poprzedzania zmiennych instancji słowem „this”, ale wydaje mi się to nieco drakońskie. Pod wieloma względami narusza DRY, ponieważ jest to zmienna instancji, po co kwalifikować ją dwukrotnie.

Mój własny styl to używanie m_ zamiast _. Powodem jest to, że istnieją również zmienne globalne i statyczne. Zaletą m _ / _ jest rozróżnienie zakresu zmiennych. Więc nie możesz ponownie użyć _ dla globalnego lub statycznego, a zamiast tego wybieram odpowiednio g_ i s_.


1
W tym pytaniu chodziło o ogólne pytanie o podkreślenia w Javie, a nie o zadawanie ich tylko przy zmiennych składowych (chociaż był to przykład w pytaniu).
Georgi

10
Więc oceniasz mnie za skomentowanie części pytania? Wydaje się trochę ekstremalne
JaredPar

1
@JaredPar - jesteś jedyną osobą, która daje dobrą alternatywną propozycję stylizacji. +1 za to.
djangofan,

Napisanie this.foo (lub this-> foo w C ++) byłoby prawdopodobnie znacznie jaśniejszym sposobem na rozróżnianie lokalnych i pól / zmiennych składowych.
Kevin

7

„Zły styl” jest bardzo subiektywny. Jeśli jakaś konwencja zadziała dla Ciebie i Twojego zespołu, myślę, że będzie to kwalifikować zły / dobry styl.

Odpowiadając na twoje pytanie: używam początkowego podkreślenia do oznaczenia zmiennych prywatnych. Uważam, że wszystko jest jasne i mogę szybko zeskanować kod i dowiedzieć się, co się dzieje.

(Jednak prawie nigdy nie używam „tego”, z wyjątkiem sytuacji, gdy chodzi o zapobieganie kolizji nazw).


Jak powiedziałeś, styl jest bardzo subiektywny. Zwykle używam thisdość swobodnie, aby wskazać zmienną składową, jeśli uważam, że wymaga ona zwrócenia na nią uwagi. Jednak nie jestem fanatykiem tego tematu.
Chris Cudmore,

6

użycie „m_” lub „_” na początku zmiennej ułatwia znajdowanie zmiennych składowych w metodach w całym obiekcie.

Dodatkową korzyścią jest wpisanie „m_” lub „_” spowoduje, że Intellsense wyświetli je jako pierwsze;)


5
Jeśli programujesz w Javie, najprawdopodobniej będziesz mieć IDE, które będzie kolorować zmienne składowe na inny kolor. „m_” jest po prostu paskudny.
JeeBee

Wolę „to”, jak się dobrze czyta:if (itsEmail.equals(email))
davetron5000

7
Wolę to. dla nazw członków. Absolutnie nie do pomylenia.
S.Lott,

5
  • Tak się składa, że ​​lubię pierwsze podkreślenia dla (prywatnych) zmiennych instancji, wydaje się łatwiejsze do odczytania i rozróżnienia.Oczywiście ta rzecz może wpędzić cię w kłopoty z przypadkami skrajnymi (np. Zmienne instancji publicznej (nie są powszechne, wiem) - tak czy inaczej im prawdopodobnie łamiesz konwencję nazewnictwa:
  • private int _my_int; public int myInt;? _my_int? )

- o ile podoba mi się ten styl _ i myślę, że jest czytelny, uważam, że jest to prawdopodobnie bardziej kłopotliwe niż warte, ponieważ jest rzadkie i prawdopodobnie nie pasuje do niczego innego w bazie kodu, której używasz.

-automatyczne generowanie kodu (np. pobierające i ustawiające generatory zaćmień) prawdopodobnie nie zrozumie tego, więc będziesz musiał to naprawić ręcznie lub zmiksować za pomocą zaćmienia na tyle, aby zostało rozpoznane.

Ostatecznie walczysz z resztą prefsów (java) świata i prawdopodobnie będziesz mieć z tego powodu pewne irytacje. I jak wspominali poprzednie postery, spójność w bazie kodu jest ważniejsza od wszystkich powyższych kwestii.


3
Skonfigurowanie Eclipse w celu zrozumienia preferencji dotyczących prefiksu (lub sufiksu) jest dość proste. W Preferencjach-> Java-> Styl kodu znajduje się tabela, w której można ustawić konwencje nazw zmiennych dla pól, pól statycznych, statycznych pól końcowych, parametrów i zmiennych lokalnych. Wydaje się, że wszystkie generatory kodu przestrzegają tych ustawień.
metasim

5

Nie bez powodu używanie podkreślenia było uważane za zły styl w dawnych czasach. Kiedy kompilator środowiska uruchomieniowego był czymś niedostępnym, a monitory miały zadziwiającą rozdzielczość 320x240 pikseli, często nie było łatwo odróżnić od _namei __name.


Dlatego OCaml nigdy nie działałby na starych komputerach.
David Tonhofer

4

Fajnie jest mieć coś do odróżnienia zmiennych prywatnych od publicznych, ale nie lubię „_” w ogólnym kodowaniu. Jeśli mogę pomóc w nowym kodzie, unikam ich użycia.


4

Oto łącze do zaleceń firmy Sun dotyczących języka Java. Nie musisz ich używać, a nawet to, że ich kod biblioteki jest zgodny z nimi wszystkimi, ale to dobry początek, jeśli zaczynasz od zera. Narzędzie takie jak Eclipse ma wbudowane elementy formatujące i narzędzia do czyszczenia, które mogą pomóc w dostosowaniu się do tych konwencji (lub innych, które zdefiniujesz).

Dla mnie „_” są zbyt trudne do wpisania :)


3

To mieszanka stylów kodowania. Jedną ze szkół myślenia jest poprzedzanie prywatnych członków podkreśleniem, aby ich odróżnić.

setBar( int bar)
{
   _bar = bar;
}

zamiast

setBar( int bar)
{
   this.bar = bar;
}

Inni będą używać podkreślenia, aby wskazać tymczasową zmienną lokalną, która wyjdzie poza zakres na końcu wywołania metody. (Uważam, że to całkiem bezużyteczne - dobra metoda nie powinna być taka długa, a deklaracja jest DOBRZE TAM! Więc wiem, że wykracza poza zakres) Edycja: Nie daj Boże programistom z tej szkoły i programistom z jej członka ! To byłoby piekło.

Czasami wygenerowany kod będzie poprzedzał zmienne znakiem _ lub __. Chodzi o to, że żaden człowiek nigdy by tego nie zrobił, więc jest to bezpieczne.


W twoim przypadku używam: setBar (int aBar) {bar = aBar; } Czytelne bez tego. lub _bar ...
Georgi

To wystarczy, ale wtedy aBar pojawia się w sygnaturze metody w API i wydaje mi się, że wygląda to niechlujnie.
Chris Cudmore,

1
Właściwie natknąłem się na przypadek, w którym automatycznie wygenerowany kod pasował do jednego ze słów kluczowych języka, więc najlepszym sposobem na uniknięcie tego było dodanie na początku znaku _.
Joe Plante

2

Myślę, że każdy styl, który łamie wytyczne dotyczące stylu języka (bez uzasadnionego powodu) jest brzydki, a zatem „zły”.

Bez wątpienia kod, który widziałeś, został napisany przez kogoś, kto pracował w języku, w którym znaki podkreślenia były dopuszczalne.

Niektórzy ludzie po prostu nie mogą dostosować się do nowych stylów kodowania ...


W większości zgadzam się z filozofią „rób tak jak inni” podczas kodowania, ale nie jako absolut. Myślę, że istnieje bardzo mocny argument, że biorąc pod uwagę rozsądne długości identyfikatorów, zmienne snake_cased_variables są łatwiejsze do odczytania niż CamelCasedVariables. Moje uzasadnienie jest takie, że wizualne zmniejszenie obciążenia poznawczego to mała rzecz, ale nadal przydatna. Ludzie doceniają białe znaki w kodzie, czytając dokumenty i słuchając muzyki. Wydaje mi się, że skrzynka wielbłąda jest zniewagą dla białych znaków w imię „wydajności”. Wydajność dla kogo?
David J.

2

Powodem, dla którego ludzie to robią (z mojego doświadczenia), jest rozróżnienie między zmiennymi składowymi i parametrami funkcji. W Javie możesz mieć taką klasę:

public class TestClass {
  int var1;

  public void func1(int var1) {
     System.out.println("Which one is it?: " + var1);
  }
}

Jeśli utworzyłeś zmienną składową _var1 lub m_var1, nie miałbyś niejednoznaczności w funkcji.

Więc to styl, a ja nie nazwałbym go źle.


W tym scenariuszu zwykle zmieniam nazwę parametru na „aVar1”. W przeciwieństwie do „the var1”.
Lluis Martinez,

1

Osobiście uważam, że język nie powinien tworzyć reguł dotyczących stylu kodowania. Jest to kwestia preferencji, użytkowania, wygody, koncepcji czytelności.
Teraz projekt musi ustawić reguły kodowania, aby zachować spójność między listami. Możesz nie zgadzać się z tymi zasadami, ale powinieneś się ich trzymać, jeśli chcesz wnieść swój wkład (lub pracować w zespole).

Przynajmniej IDE, takie jak Eclispe, są agnostyczne, co pozwala na ustalanie reguł, takich jak zmienne przedrostki lub przyrostki, różne style umieszczania nawiasów klamrowych i zarządzanie przestrzenią itp. Możesz więc użyć go do ponownego sformatowania kodu zgodnie z własnymi wytycznymi.

Uwaga: Należę do tych, którzy zachowują swoje stare nawyki z C / C ++, kodując Javę z prefiksami m_ dla zmiennych składowych (i s_ dla zmiennych statycznych), poprzedzając wartości logiczne z początkowym b, używając początkowej dużej litery dla nazw funkcji i wyrównując nawiasy klamrowe. .. Horror dla fundamentalistów Java! ;-)
Zabawne, takie są konwencje stosowane w mojej pracy ... prawdopodobnie dlatego, że główny początkowy programista pochodzi ze świata MFC! :-RE


0

to tylko twój własny styl, nic złego kodu stylu i nic dobrego kodu stylu, po prostu odróżnij nasz kod od innych.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.