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ł.
code-quality
coding-style
Daniel C. Sobral
źródło
źródło
:
, jak w:(){ :;:& };:
, powiedziałbym, że większość ludzi uważa, że jest całkiem zły. ;)Odpowiedzi:
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
i
jest 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.źródło
for
pętli nazwałbym indekscustomerCounter
lub 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.i
ij
są pospolitymi nazwami, które każdy programista powinien zrozumieć IMO.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
,j
są oczywiście stosowane jako wskaźniki, są krótkie, ale bardzo pouczające.bnt
jest brzydkaclose
lubcloseButton
ma 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ęn
lokalną 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 (v
dla wartości to inny przykład).Dlatego nazwy zmiennych powinny mieć charakter informacyjny i nie ma znaczenia, że są krótkie lub długie .
źródło
close = true
;)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:
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.
źródło
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ś widziszs_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.
źródło
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:
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!
źródło
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ć.
źródło
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.
źródło
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
, ik
dla indeksów,dx
na 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 takiet47
. („Co to znaczy i dlaczego różni się odt46
?”) 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
&DistanceBetweenYAxisAbscissae
jest 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
deltaX
bez 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.źródło
Przeciwnie, myślę, że długie identyfikatory są gorsze niż krótkie identyfikatory (chyba że masz do czynienia ze stałymi). Używanie
TheVariableThatHoldsTheCapacityOfMyContainerClass
sprawia, że kod jest bardziej podatny na błędy niż używanieCapacity
.źródło
var total = Capacity + Capacity2;
CoCapacity
zawiera i coCapacity2
zawiera? Do czego będą wykorzystywane? Poszukiwanie wskazówek kontekstowych marnuje czas. Natomiast jeśli jest napisane takvar totalStorageCapacity = truckCapacity + trailerCapacity;
, jak wiem, o czym mówimy.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.
źródło
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.
źródło
i
w pętlifor (int i=0; i<dst.size(); ++i) dst[i] += src[i]
powinno być prawnie zabronione.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ć?
źródło
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.
źródło
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.
źródło
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.
źródło
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 ?!
źródło