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

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ł.

• http://evergreen.loyola.edu/chm/www/Papers/SCP2009.pdf

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.

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 .

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.

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.

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!

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ć.

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.

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.

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.

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.

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.

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ć?

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.

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.

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.

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 ?!