Czy krótkie identyfikatory są złe? [Zamknięte]

26

Czy krótkie identyfikatory są złe? W jaki sposób długość identyfikatora koreluje ze zrozumieniem kodu? Jakie inne czynniki (oprócz zrozumienia kodu) mogą być brane pod uwagę, jeśli chodzi o identyfikatory nazw?

Aby tylko utrzymać jakość odpowiedzi, zauważ, że są już pewne badania na ten temat!

Edytować

Ciekawe, że wszyscy albo nie uważają, że długość jest odpowiednia, albo wolą większe identyfikatory, gdy oba podane przeze mnie linki wskazują, że duże identyfikatory są szkodliwe!

Uszkodzony link

Poniższy link wskazywał na badania na ten temat, ale teraz jest zepsuty, wydaje mi się, że nie mam ze sobą kopii tego artykułu i nie pamiętam, co to było. Zostawiam to tutaj na wypadek, gdyby ktoś inny to rozgryzł.

Daniel C. Sobral
źródło
5
Punkt danych. Mój ulubiony krótki identyfikator to :, jak w :(){ :;:& };:, powiedziałbym, że większość ludzi uważa, że ​​jest całkiem zły. ;)
@fennec: Bomby widełowe są zwykle.
Josh K,
Sprawdź to pytanie o przepełnieniu stosu. Jest komentarz na temat praktyki programowania książki, którą powinien przeczytać każdy programista.
slu
1
To, że należy unikać dłuższych nazw, nie oznacza, że ​​powinieneś podjąć dodatkowy wysiłek, aby je skrócić ze względu na krótkość.
JeffO,
1
@cessor Zabawne, że coś, co miało być o badaniach, zostało zamknięte jako oparte na opiniach. Niestety zgadzam się, biorąc pod uwagę otrzymane odpowiedzi.
Daniel C. Sobral,

Odpowiedzi:

67

Najlepsza „reguła”, jaką słyszałem, to to, że długości nazw powinny być proporcjonalne do długości zakresu zmiennej. Tak więc indeks ijest w porządku, jeśli treść pętli ma kilka linii, ale lubię używać czegoś bardziej opisowego, jeśli będzie dłuższa niż 15 linii.

Uwaga do samodzielnego wymyślenia imienia
źródło
6
Nigdy o tym nie słyszałem i nie sądzę, aby ta zasada poprawiła czytelność kodu.
NimChimpsky,
8
@Nim: Zgadzam się. Nawet w krótkiej forpętli nazwałbym indeks customerCounterlub coś w tym rodzaju. Wymaga minimalnego dodatkowego wysiłku i sprawia, że ​​Twój kod jest o wiele lepszy. Używanie krótkich zmiennych dla krótkiego zasięgu brzmi jak wymówka, aby być leniwym.
Nikt
2
Hmm, to nie jest dla mnie reguła ani wytyczna, ale sposób na skłonienie cię do myślenia o długości iw tym kontekście ma to jakiś sens. Z pewnością nie uważam tego za usprawiedliwienie dla lenistwa (choć zgodzę się, że niektórzy mogą to uznać za takie). Moje identyfikatory są znacznie dłużej niż nie (oznaki wczesnego uczenia się pascal), z wyjątkiem teraz, gdy przechodzę do takich rzeczy, jak zapytania linq i wyrażenia lambda, gdzie wydaje mi się, że 1, 2 lub 3 znaki (zwykle inicjały typu) mają sens .
Murph,
33
+1 Szczerze mówiąc, „opisowa” nazwa to po prostu szum w pięcioliniowej pętli dla pętli; Myślę, że większość ludzi ma dobre pojęcie o tym, co robisz z „i”. Użyłem opisowych nazw w zagnieżdżonych pętlach, ale mają one większy zasięg.
Jeremy,
18
+1 - Używanie ii jpospolitymi nazwami, które każdy programista powinien zrozumieć IMO.
TheCloudlessSky,
48

Każda zmienna powinna mieć znaczenie, a jej nazwa jest częścią tego znaczenia. I bardzo ważna część, ponieważ pomaga czytelnikowi zrozumieć, do czego służy, bez zagłębiania się w algorytm. i, jsą oczywiście stosowane jako wskaźniki, są krótkie, ale bardzo pouczające. bntjest brzydka closelub closeButtonma znaczenie. Dlatego krótkie lub długie nie jest najważniejszym kryterium dla nazwy zmiennej, powinno mieć znaczenie. Znaczenie jest silnie uzależnione od kontekstu. Na przykład możesz nadać bardzo krótką nazwę nlokalną zmienną łańcuchową, która jest używana w małym bloku kodu, powiedzmy 10 wierszy i odnosi się do nazwy właściwości ( vdla wartości to inny przykład).

Dlatego nazwy zmiennych powinny mieć charakter informacyjny i nie ma znaczenia, że ​​są krótkie lub długie .

duros
źródło
2
+1, a dla przypomnienia, zamknij i zamknij Przycisk też nie są synonimami. Close jest czasownikiem i dlatego powinna być nazwą funkcji lub metody. Chociaż closeButton jest rzeczownikiem i oczywiście powinien być nazwą przycisku uruchamiającego funkcję zamykania.
CaffGeek,
close jest przymiotnikiem, np close = true;)
Armand
13

Użyję identyfikatora, który opisuje zmienną, niezależnie od długości.

Przypadki i, j i k są same w sobie tak wszechobecne, że same się opisują, automatycznie wiesz, że są to wskaźniki pętli. To samo możesz powiedzieć o:

foreach loop (Strings s : myString)

Jednak IDE udostępnia teraz narzędzia do uzupełniania kodu, więc jedyny negatywny efekt uboczny bardzo długich i opisowych identyfikatorów został usunięty.

Z przyjemnością dodam i dodam dodatkowe słowo do identyfikatora, jeśli jest to wymagane do wyjaśnienia celu zmiennej.

NimChimpsky
źródło
3
BTW, użycie i, j i k dla wskazań pętli sięga ponad 50 lat wstecz do FORTRAN. Zmienne zaczynające się od liter od I do N są domyślnie typu INTEGER. Zmienne zaczynające się od dowolnej innej litery są domyślnie PRAWDZIWE. To naturalnie doprowadziło do użycia I, J i K do indeksów pętli. (Konwencja FORTRAN prawdopodobnie powstała w wyniku użycia tych zmiennych używanych w równaniach matematycznych wcześniej).
tcrosley,
2
Drugi artykuł, który podłączyłem, wykazał, że bardzo długie identyfikatory opisowe zmniejszają zdolność rozumienia kodu, co jest sprzeczne z uwagą „tylko negatywny efekt uboczny”.
Daniel C. Sobral,
3
Prawdziwym negatywnym efektem ubocznym bardzo długich identyfikatorów jest ich czytelność. Trudno na pierwszy rzut oka stwierdzić, czy dwa bardzo długie identyfikatory są takie same, czy różne, i może być trudne wybranie wszystkich elementów wyrażenia z bardzo długimi identyfikatorami.
David Thornley,
tcrosley - Dodam, że tylko dlatego, że pochodzi z Fortranu, nie ma powodu, aby kontynuować taką praktykę. Zdecydowanie odradzam korzystanie z liczników iteratora / pętli zwanych „i”, „j”, „k” itp. Jest to zwykłe lenistwo intelektualne. Wszechobecny <> dobry.
szybko_nie
9

Nie są tak złe, jak wprowadzające w błąd identyfikatory. Nie przeszkadza mi debugowanie kodu, w którym identyfikatory to tylko jedna litera, ale z chwilą pojawienia się różnych konwencji nazewnictwa staje się to denerwujące. Na przykład, jeśli gdzieś widzisz strPersonID, a następnie gdzieś widzisz s_EmployeeID, to mylące jest stwierdzenie, czy są to oba ciągi i czy jest jakaś różnica. Również, jeśli zmienne są kopiowane i wklejone ( pmapIntString = new std::map<int,int>) i są całkowicie niepoprawne, będę się martwić.

Jeśli chodzi o mnie, dodaję w kodzie komentarze do użytych ważnych zmiennych i staram się zachować standard podany w wytycznych programistycznych. Jeśli nie ma standardu, staram się zachować tę samą konwencję nazewnictwa w całym kodzie.

Manoj R.
źródło
5

Walczę ...

Zawsze używam opisowych nazw jako identyfikatorów, ale ostatnio używałem bardzo krótkich identyfikatorów.

Myślę, że to zależy od kontekstu kodu:

  • Jeśli piszesz złożone funkcje (algorytmy), ZAWSZE używaj krótkich identyfikatorów (najlepiej pojedyncze znaki)
  • Pisząc wartości parametrów dla funkcji, używaj nazw opisowych.

Myślę, że zależy to również od tego, jak gęsty jest kod. Czasami posiadanie nazwisk utrudnia czytanie.

Czasami bez nazw jest to całkowicie tajemnicze!

Darknight
źródło
1
Jeśli jednak piszesz złożone algorytmy, czy nie chciałbyś, aby identyfikatory były bardziej opisowe dla osób, które oglądają Twój kod po raz pierwszy?
Maks.
Kiedy może być odpowiedni identyfikator jednoznakowy?
Amir Afghani,
1
Kiedyś tak myślałem, ale tak naprawdę to nie jest przypadek, spróbuj sam. Weź złożony algorytm i wypróbuj opisowe nazwy vs zmienne jednoliterowe.
Darknight
1
Zgadzam się, ale tylko w przypadku dłuższych złożonych formuł, ponieważ mają one tendencję do wydłużania się i nawet wtedy można użyć funkcji (nazw funkcji), aby opisać, jakie są części tej formuły.
Emile Vrijdags,
1
Jeśli jest tak złożony i ma wzorce, wzorce te należy podzielić na funkcje
CaffGeek,
3

Myślę, że same w sobie nie są złe , ale są mało pouczające, chyba że są bardzo standardowe.

Tak więc zmienne pętli będące i, j i k są tak standardowe, że nie ma powodu, aby ich nie używać, jeśli tworzysz indeksowaną pętlę.

Innym miejscem, w którym użyję bardzo krótkiego identyfikatora, jest deklarowanie zmiennej tymczasowej, która wyjdzie poza zakres w kilku liniach czasowych - na przykład zmienna tymczasowa z pętli foreach. Jeśli nie będzie się do niego nigdzie odwoływał, każdy może przeczytać kod i zobaczyć deklarację i śledzić, do czego jest używany. Jeśli jednak będzie on używany przez więcej niż pięć lub sześć linii, będę starał się nadać mu jaśniejszą nazwę.

Poza tym staram się używać informacyjnych identyfikatorów długości - szczególnie na poziomie klasy chcę identyfikatora, który można odczytać i dowiedzieć się, do czego służy zmienna. Jeśli stają się zbyt długie (i czasami widzę kod z czterema lub pięcioma słowami połączonymi razem dla identyfikatora), mam tendencję do traktowania tego jako zapachu kodu - jeśli potrzebuję tyle tekstu, aby odróżnić moje zmienne, to w rzeczywistości jest to grupa, która można lepiej przechowywać w haszapie lub liście? Czy mogę stworzyć jakiś obiekt, aby dokładniej modelować te dane? Czasami nie można, ale bardzo długi identyfikator jest wskaźnikiem, że warto tu się przyjrzeć.

glenatron
źródło
3

Zgadzam się bardzo z innymi odpowiedziami tutaj, ale chciałbym zwrócić uwagę na jeszcze jeden czynnik, który moim zdaniem jest często pomijany. Dobre imię to często nazwa idiomatyczna dla kodu. Może to być na poziomie języka, algorytmu lub niektórych wewnętrznych idiomów dla danej bazy kodu. Chodzi o to, że chociaż nazwa może nic nie znaczyć dla kogoś, kto nie zna domeny kodu, nadal może być najlepszą nazwą w danym kontekście.

Harald
źródło
3

Nazywanie zmiennej jest zawsze ćwiczeniem w równoważeniu wyjątkowości i zrozumiałości. Długość nazwy jest powiązana z nimi na różne sposoby. Dłuższe nazwy łatwiej jest uczynić unikalnymi; nazwy o średniej długości są zazwyczaj bardziej zrozumiałe niż nazwy, które są zbyt krótkie lub zbyt długie.

Bardzo krótki Nazwa zmiennej jest użyteczna tylko jeśli ma za to sprawia, że zrozumiała (na przykład i, j, i kdla indeksów, dxna odległość wzdłuż osi) lub jego zakresu, który jest na tyle mały, aby wszystkie odniesienia będzie widoczna na raz (na przykład , temp). Najgorsze nazwy zmiennych na świecie to takie t47. („Co to znaczy i dlaczego różni się od t46?”) Dzięki Bogu, że styl nazewnictwa przeszedł głównie przez FORTRAN, ale właśnie tutaj zakorzenione jest pragnienie dłuższych nazw zmiennych.

Jak pokazał twój oryginalny artykuł, zbyt długie nazwy są również trudne do odczytania, ponieważ subtelne różnice wewnętrzne można przeoczyć, gdy spojrzy się na kod. (Różnica między DistanceBetweenXAxisAbscissae& DistanceBetweenYAxisAbscissaejest bardzo trudna do szybkiego znalezienia.)

Jak wskazano wcześniej NoteToSelf, wymagania dotyczące unikalności nazwy zależą przede wszystkim od zakresu, w jakim nazwa musi być unikalna. Indeks 5-liniowej pętli może wynosić i; indeks aktywnego rekordu przekazywanego z funkcji do funkcji powinien mieć znacznie bardziej opisową nazwę.

Zmienna lokalna dla funkcji może mieć małą opisową nazwę, jak deltaXbez problemu. Statyczna zmienna delta X w module musi mieć nazwę, która odróżnia ten deltaX od innych deltaX w tym samym module, co czyni go dłuższym. A globalna zmienna delta X musi być unikalna we wszystkich modułach i wszystkich możliwych innych modułach, które mogą zostać utworzone, prawdopodobnie przez połączenie nazwy modułu z inną nazwą opisową. Jest to jeden z wielu problemów związanych z globals; aby były użyteczne, unikalne nazwy muszą być wystarczająco długie, aby utrudniać ich odczytanie.

Erik Johnson
źródło
2

Przeciwnie, myślę, że długie identyfikatory są gorsze niż krótkie identyfikatory (chyba że masz do czynienia ze stałymi). Używanie TheVariableThatHoldsTheCapacityOfMyContainerClasssprawia, że ​​kod jest bardziej podatny na błędy niż używanie Capacity.

Maks
źródło
1
Z przyjemnością dowiesz się, że jedno z badań, które podłączyłem, wspiera twoje rozumowanie, jeśli nie z tych samych powodów. ;-)
Daniel C. Sobral
1
Bardzo łatwo jest również źle odczytać bardzo długie identyfikatory, być może wprowadzając je w błąd lub nie zdając sobie sprawy, że dwa z nich są takie same.
David Thornley,
2
TheVariableThatHoldsTheCapacityOfMyContainerClass jest większy niż uważałbym go za „długi” - dziesięć słów jest za długie, aby CamelCase mu pomógł; potrzebujesz spacji, aby było to czytelne.
Richard Gadsden,
1
Jasne, ale to słomiany człowiek. Twój przykład długiej nazwy dodaje gadatliwość, ale nie zawiera informacji. Rozważ przypadek, w którym masz wiele zmiennych odnoszących się do różnych form pojemności. Wtedy naprawdę możesz chcieć nazw, które rozróżniają cele, takich jak initalCapacity lub finalCapacity.
Charles E. Grant,
2
@Maxpm, var total = Capacity + Capacity2; Co Capacityzawiera i co Capacity2zawiera? Do czego będą wykorzystywane? Poszukiwanie wskazówek kontekstowych marnuje czas. Natomiast jeśli jest napisane tak var totalStorageCapacity = truckCapacity + trailerCapacity;, jak wiem, o czym mówimy.
CaffGeek,
2

Same w sobie krótkie identyfikatory nie są złe. Wybór dobrych nazw (krótkich lub długich) służy przejrzystości kodu. Wybór identyfikatorów w celu zapewnienia przejrzystości kodu jest ważniejszy niż spełnienie pewnych wymagań dotyczących minimalnej długości. Ogólnie rzecz biorąc, oznacza to pisanie nieco dłuższych znaczących nazw.

dietbuddha
źródło
+1 powiedziałeś to bardzo dobrze, nie mogłem znaleźć moich słów, kiedy napisałem odpowiedź :-)
ComputerSaysNo
1

Obserwacja, którą obserwowałem przez lata i dziś jest mniej niż 10 lub 15 lat temu. Programiści, którzy nie potrafią pisać, będą tymi, którzy będą walczyć z zębami o zmienne nazewnictwo. Są to te ze wszystkimi 1-3-literowymi nazwami zmiennych.

Tak więc radzę użyć sensownej nazwy, którą wypowiedziało wielu komentujących, a następnie nauczyć się pisać. Zastanawiałem się nad dodaniem testu typowania do wywiadów, aby zobaczyć, gdzie są ludzie, ale zaczynam widzieć znacznie mniej osób nietypowych, ponieważ komputery stają się większą częścią społeczeństwa.

Bill Leeper
źródło
2
Właściwie nie widziałem takiej korelacji. Jeśli coś wydaje się, ludzie z języków OO wybierają długie identyfikatory, a osoby z języka funkcjonalnego wybierają krótkie. Podważa to zarzut, że OO pomaga w modelowaniu. :-)
Daniel C. Sobral
Nie zapominaj, że nazwiska trzeba nie tylko wpisywać, ale także czytać. Używanie zbyt długich identyfikatorów może znacznie zmniejszyć czytelność. Używanie czegokolwiek innego niż iw pętli for (int i=0; i<dst.size(); ++i) dst[i] += src[i]powinno być prawnie zabronione.
maaartinus
1

Pierwszy artykuł, do którego linkujesz, wygląda interesująco, ale jego wniosek jest taki, że nie znaleźli żadnych istotnych dowodów na poparcie lub przeciw hipotezie, że „wskazówki uziemiające”, w tym znaczące nazwy zmiennych, pomagają w zrozumieniu kodu. Używane spojrzenie zatrzymuje czas jako przybliżenie do rozumienia kodu, co jest interesujące, ale nie jest to zwykły wsad.

Obawiam się, że drugi artykuł był po prostu głupi. Pierwszy problem polega na tym, że podane przez nich przykłady długich nazw są długie, nie dostarczając żadnych dodatkowych informacji. Myślę, że wszyscy możemy się zgodzić, że wydłużanie nazwy zmiennej tylko po to, żeby była dłuższa, jest głupie. Ich przykładem nazywania zmiennej distance_between_abscissae zamiast dx jest człowiek słomy.

Co ważniejsze, ich eksperyment jest raczej testem prostego zapamiętywania niż zrozumienia. Sprawdza zdolność uczestników do uzupełnienia brakujących elementów nazwy zmiennej, gdy są prezentowane na liście bez kontekstu. Tak, dłuższe nazwy są trudniejsze do zapamiętania, ale kiedy koduję, nie zapamiętywam nazw zmiennych, używam ich do zapewnienia kontekstu. Przypuszczam, że można argumentować, że trudność zapamiętania długiej zmiennej utrudnia pisanie kodu, ale kod jest odczytywany znacznie częściej niż jest zapisywany, więc które działanie należy zoptymalizować?

Charles E. Grant
źródło
Zauważ, że drugi artykuł wyraźnie stwierdza, że „osiem nazw użytych w ośmiu pytaniach zostało wyodrębnionych z kodu produkcyjnego”. Nie testują również samego zapamiętywania, ale również poprawności.
Daniel C. Sobral,
1

Jedną z moich głównych miar służących do ustalenia, czy wiersz kodu jest czytelny, czy nie, jak wiele innych kontekstów z innych wierszy musi być odczytanych, aby naprawdę mieć pewność, że rozumiesz, co robi wiersz.

Łatwo powiedzieć, że „każdy powinien być w stanie zrozumieć, że i, j i k są zmiennymi pętlowymi”. I przez większość czasu jest to naprawdę oczywiste. Ale nadal staram się zachować pokorę i profesjonalizm w tym zakresie i zakładam, że przy programowaniu łatwo jest popełniać błędy. Więc jeśli mam pętlę przez tablicę Grobble, nazwiebym zmienną pętli grobbleIndex. Mogę również zaakceptować i jako skrót indeksu. Kiedy używasz ij i k, trudniej jest dostrzec błąd, taki jak użycie niewłaściwego indeksu z niewłaściwą tablicą i tak dalej. I staje się jeszcze gorzej, gdy masz wewnętrzną pętlę.

PS. Kiedy pisałem tę odpowiedź, kodowałem trochę javascript na 10-calowym mini laptopie z pionowo podzielonym ekranem w vimie i nadal poświęciłem czas na nazwanie moich zmiennych pętli rowIndex i columnIndex.

Sam
źródło
0

W niektórych aplikacjach krótka zmienna po prostu nie może wyjaśnić danych w zmiennej. Krótki lub długi nie ma znaczenia. Użycie dłuższej zmiennej nie powoduje spowolnienia kodu. Na pewno więcej wysiłku wymaga wpisanie długiej nazwy zmiennej, ale przynajmniej osoba, która odczyta kod 6 miesięcy później (może to być Ty), będzie w stanie zrozumieć, co się dzieje, bez konieczności zapisywania śladów, zakładając, że jest to w ogóle możliwe.

rsman
źródło
0

Myślę, że ideałem jest, aby nazwy były opisowe, chyba że ...

Idea, że ​​nazwy mogą (być może powinny) być krótsze - a przez to mniej opisowe - jeśli mają ograniczony zakres, jest tylko jednym powodem odejścia od ideału.

Osobiście często używam krótkich nazw dla niewielkiej liczby podmiotów, do których wielokrotnie się odwołuję. Na przykład często nazywane podprogramami specyficznymi dla aplikacji.

FumbleFingers
źródło
-2

Nigdy nie użyłbym nazw identyfikatorów składających się z mniej niż 4-5 znaków, na przykład zmienną pętli może być Indeks lub jIndex lub kIndex w zależności od tego, ile wewnętrznych pętli potrzebuję, aby coś osiągnąć, ale w przypadku innych nazw powiedzmy „klucz” „String LKey” lub „int LKey”, „L” dla zmiennej lokalnej, jeśli jest to zmienna metody lub „F” dla zmiennej klasy prywatnej, wszystkie inne identyfikatory, takie jak inne wymienione wcześniej, powinny wyjaśniać przyczynę swojego istnienia w nazwie, w przeciwnym razie Zakres „identyfikatora” jest bezużyteczny, prawda ?!

Komputer mówi nie
źródło
5
Jakie dodatkowe informacje przekazuje „indeks”, a nie „i”? Długie nazwy zmiennych, które nic nie mówią, są gorsze niż nazwy jednoznakowe.
Anon.
2
Ostatnio napisałem kilka rzeczy, które działały na siatce 3d, i miałem wiele zmiennych o nazwach x, yiz. Biorąc pod uwagę kontekst, były one doskonale opisowe.
Loren Pechtel