Nazewnictwo opisowe a 80 linii znaków [zamknięte]

17

Często słyszę te dwie cenne praktyki programowania: (1) wiersze kodu powinny mieć maksymalnie 80 znaków i (2) używają opisowych nazw zmiennych, metod, klas itp. Rozumiem jednak uzasadnienie obu tych porad. , wydają się często kompromisami. Jeśli utrzymam mój kod poniżej 80 znaków / wiersz, w rezultacie będę używał mniej opisowych nazw (szczególnie w Pythonie, w których każde wcięcie liczy się jako 4 znaki), ale jeśli użyję więcej opisowych nazw, to kończę wierszem o długości ponad 80 znaków.

Moje pytanie brzmi zatem, która z tych dwóch rad jest ważniejsza, jeśli trzeba dokonać wyboru? Zastanawiam się nad tym jako niezależny programista (hobbysta), ale co ważniejsze z perspektywy inżyniera oprogramowania pracującego dla większej firmy.

mjgpy3
źródło
4
@BillyONeal Z dużymi ekranami, 120 :)
18овић
4
Myślę, że potrzebuję co najmniej 130
9
8
Wolę 80, ponieważ mogę wtedy łatwo otworzyć 2 pliki obok siebie na moim notebooku.
Honza Brabec
5
Linie dłuższe niż 80 znaków stają się nieczytelne. Więc 80 to dobry limit. Opisowe nie muszą być zbyt szczegółowe. I to zależy od zakresu: małe nazwy krótkich zmiennych, duże nazwy dłuższych. I za wszelką cenę unikaj zmiennych o dużym zasięgu. Jeśli jesteś przy tym, użyj funkcjonalnego języka i podziel kod na mniejsze funkcje, gdy wcina się zbyt głęboko -> bardzo mały zakres == krótkie zmienne. Nazwy funkcji są podobne, ale zwykle nieco dłuższe, ponieważ ich zakres jest większy.
Peer Stritzinger
4
@ ott--: Czy widziałeś edytor, który faktycznie może przełamać długą linię, zgodnie ze składnią C ++, i przedstawić kontynuację wciętą o jeden poziom więcej niż początek? W przeciwnym razie taka sugestia jest bezużyteczna.
Jan Hudec

Odpowiedzi:

34

Miej kilka wcięć, swoje opisowe nazwy i nie bój się przekraczać linii.

Trzymaj kilka wcięć.

Często, gdy walczę między wcięciami a nazewnictwem opisowym, cofam się o krok i patrzę na poziom wcięcia. Jeśli wcinasz więcej niż 3 lub 4 poziomy (2 poziomy są automatyczne i nieuniknione w wielu przypadkach. Przeczytaj: definicja metody klasy), możesz przebudować swój kod, wyodrębniając funkcjonalność do funkcji lub metody.

Twoje imiona opisowe

Zawsze powinieneś zachować opisy. Nazwy opisowe tworzą kod samokontrujący. W niektórych przypadkach możesz spróbować skrócić nazwy, ale na pierwszym miejscu jest czytelność.

Nie bój się złamać linii

Cholera się zdarza. Jeśli przekroczysz 80 znaków i nie widzisz, aby odzyskać miejsce w linii - przerwij je. Większość języków nie przejmuje się łamaniem linii, więc podziel linię na wiele. Nie wybieraj przypadkowej lokalizacji. Trzymaj logicznie pogrupowane rzeczy i wciskaj kolejny poziom, gdy przekroczysz linię.

Craige
źródło
3
Należy zauważyć, że nazwy opisowe to nie to samo, co nazwy długie. Unikanie powtarzania rzeczy, które można łatwo zobaczyć z kontekstu, oraz garść starannie dobranych skrótów (tylko w przypadku bardzo popularnych pojęć) mogą znacznie przyczynić się do uzyskania krótkich opisowych nazw.
Jan Hudec
18

Dlaczego nie oba?

Przede wszystkim „opisowy” i „pełny” to nie to samo. Na przykład, jeśli piszesz dość lokalną pętlę, ijest to bardzo dobra nazwa zmiennej dla zmiennej pętli; current_iteration_index, choć prawdopodobnie bardziej opisowy i zdecydowanie bardziej szczegółowy, jest znacznie gorszy i w ogóle nie dodaje żadnych informacji, ponieważ użycie ijako zmiennej pętli jest powszechnie akceptowane i nie ma innego znaczenia iniż to.

Dobre nazwy zmiennych mają charakter opisowy, ponieważ programista zaznajomiony z idiomem języka i konwencjami bazy kodu może łatwo odgadnąć, jaka jest ich rola, ale są również wystarczająco zwięzłe, aby zachować zwartość.

Limit 80 znaków, pierwotnie będący konsekwencją ograniczeń technicznych terminali tekstowych z lat 70. XX wieku, jest nadal ceniony przez wielu dzisiaj, i mimo że nadal istnieją przyczyny techniczne (maksymalne długości linii w niektórych protokołach sieciowych, w szczególności związane z pocztą e-mail), bardziej istotne są przyczyny psychologiczne i społeczne. Okazuje się, że długości linii wokół znaku 66 znaków zapewniają najwygodniejsze doznania w prozie w języku naturalnym (rozmiar czcionki, co ciekawe, nie robi dużej różnicy, a co za tym idzie, nie zmienia też rozmiaru ekranu ani papieru); 80-znakowe limity linii są dość zbliżone do tego, ale ponieważ większość typowego fragmentu kodu jest zwykle wcięta co najmniej na jednym lub dwóch poziomach (co oznacza od 4 do 16 znaków, w zależności od ustawień wcięcia),

Innym efektem trzymania się linii 80-znakowych jest to, że jest to całkiem niezły wskaźnik, kiedy sprawy są zbyt skomplikowane. Długie linie są zwykle spowodowane przez jedną z następujących czynności:

  • Funkcje z długą listą argumentów; nie jest to przyjemne, ponieważ utrudniają czytelność i mogą łatwo powodować subtelne błędy, np. gdy ludzie zamieniają kolejność argumentów w sposób, który nie jest w stanie złapać kompilatora.
  • Złożone wyrażenia, często spotykane w warunkowych (np. if ((user.isLoggedIn && user.hasPermission(page.getRequiredPermission()) && !user.isBanned) || page.getRequiredPermission() == null)); to również jest zwykle trudne do odczytania, a kod powinien zostać przepisany na coś bardziej uporządkowanego. Najprawdopodobniej wyrażenie robi zbyt wiele i należy je rozdzielić na metodę lub funkcję.
  • Długie literały używane w wywołaniach funkcji lub wyrażeniach, np print(translate(LANG_EN, LANG_ES, "This is the home page. Feel welcome to click around and see what we have."));. Przenieś literał na zmienną lub stałą; może nadal przekraczać długość linii, ale jeśli będziesz to robić konsekwentnie, czytelnik może przynajmniej bezpiecznie zignorować niewidoczną część linii, zakładając, że następuje tylko pozostała część literału. Lub jeszcze lepiej, przenieś literały poza kod i do zewnętrznego magazynu danych (plik, baza danych, cokolwiek).
  • Głęboko zagnieżdżone instrukcje, np. Sześć poziomów ifinstrukcji w metodzie klasy (to 32 kolumny wcięć dla typowych ustawień). Ponownie, głębokie zagnieżdżanie tworzy złożony i trudny do odczytania kod i należy go unikać jak zarazy - mówiąc prosto, głębokie zagnieżdżanie przepełnia stos ludzkiego mózgu podczas czytania.

Wszystko to są ostatecznie symptomy rzeczy, których wolałbyś nie mieć w swojej bazie kodu na dłuższą metę, a egzekwowanie limitów 80 znaków jest przyjemnym i prostym sposobem, który pomaga zmniejszyć złożoność i zwiększyć czytelność. (Nie oznacza to, że nie można napisać idealnie nieczytelnego kodu w 80 kolumnach: różne konkursy zaciemnionego kodu są wyraźnym kontrprzykładem).

tdammers
źródło
1
+1: Świetna odpowiedź, z wyjątkiem tego, że nie zgadzam się z odsuwaniem literałów od kodu. Kiedy wiesz, którego literału szukasz, możesz równie dobrze szukać go w zasobach lub kodzie, ale kiedy pracujesz z kodem i musisz zmodyfikować literał, szukanie go w oddzielnym pliku jest dość rozpraszające. Zauważ też, że we wszystkich językach istnieje sposób dzielenia literałów na wiele wierszy, co zrobiłbym w takim przypadku.
Jan Hudec
Oczywiście zdanie użyte jako przykład długiej literału nie ma miejsca w kodzie źródłowym. Takie rzeczy są dostępne w szablonach stron. Ale dla rzeczy takich jak komunikaty o błędach wolę trzymać je z kodem, który je emituje.
Jan Hudec
@JanHudec: Jasne, przeniesienie literałów do pliku danych nie zawsze ma sens. Mówię jednak o zbyt długich literałach, a przy tych rzadko spotykałem się z sytuacją, w której zdefiniowanie ich w innym miejscu pogorszyłoby kod: długość tekstu jest uciążliwa dla czytania, a jego znaczenie może być łatwo skondensowane w nazwę stałą lub zmienną, którą następnie zdefiniujesz w innym miejscu. Komunikaty o błędach są, jak sądzę, wezwaniem do oceny.
tdammers
16

Nazewnictwo opisowe jest przez FAR bardziej ważne. W większości interfejsów możemy przewijać, aby zobaczyć dłuższe linie. W żadnym wypadku system nie może pomóc w tłumaczeniu źle nazwanych zmiennych i funkcji.

Matt S.
źródło
2
To. Przestań łamać linie na znakach X, pozwól IDE sobie z tym poradzić. W przeciwnym razie przeszkadzasz wszystkim innym użytkownikom (w tym przyszłym tobie!), Których ekrany / IDE mogą obsługiwać 2 * X znaków z kodem, który nie mieści się już na jednej stronie.
Konerak,
4
Pytanie dotyczyło jednak nie tylko długich nazwisk. I nie zgadzam się, że nazwiska powinny być długie - przez większość czasu powinny być krótkie . Opisowe długie nazwy mogą utrudniać czytanie kodu niż nieco mniej opisowe, ale krótsze nazwy! (Zbyt długie linie są na ogół trudne do odczytania.)
Konrad Rudolph
4
Nie zgadzam się. Jeśli nie widzę kodu od razu, trudno go odczytać, bez względu na to, jak opisowe są nazwy.
Jan Hudec
4

80 znaków w wierszu nie jest trudne do spełnienia, nawet nazewnictwo jest długie, ponieważ istnieje wiele sposobów na rozbicie pojedynczej linii długiego kodu na wiele krótkich kodów, np. Mogę rozbić instrukcję warunkową w C na wiele linii, aby zmieściła się w mniej niż 40 postacie,

if ( a == b || c == d  || d == e
    || c == e || c == a || c == k
    || c == l)

możesz także podzielić linię wywołań funkcji na wiele linii.

Dlatego obie zasady nazewnictwa opisowego i 80 linii znaków nie są sprzeczne, mogą współistnieć, aby poprawić czytelność.

neo
źródło
2
Czy 80 znaków naprawdę poprawia czytelność? Jaki ekran nie może teraz łatwo zrobić 120?
Billy ONeal
7
@BillyONeal łatwiej jest zeskanować ponad 80 szerokości niż ponad 120 szerokości
maniak zapadkowy
2
aktualności przerwa papier do kolumn, a może masz więcej informacji od UX ux.stackexchange.com/questions/3618/...
neo
1
Przerwanie warunku logicznego poprawia czytelność, gdy podziały linii odpowiadają strukturze warunku, ale niekoniecznie, jeśli odpowiadają one tylko pewnym ograniczeniom.
mikołak
1
@BillyONeal: większość ekranów potrafi zrobić 120, ale prawie żaden nie może zrobić 240. Czy nigdy nie porównujesz różnic?
Hubert Kario
0

Limit 80 to coś, co dawno powinno było zostać zwiększone. Należy pamiętać, że ten limit jest stosowany od wieku, kiedy długość każdego identyfikatora była ograniczona do 8 znaków i tylko jednej czcionki na ekranie / drukarce. Brak możliwości zmiany rozmiaru czcionki.

Boże, mamy teraz inną technologię sitodruku. Mamy bardzo różne języki programowania. Nie ma już powodu, aby używać 80 znaków. Zwiększ go do co najmniej 120 znaków.

Nawet wtedy nie powinno być twardego limitu. Idziesz jedną postać ponad linię? Nic się nie dzieje!

Edytować:

Szczegółowe odpowiedzi na temat historii limitu 80 znaków

Liczba znaków w wierszu na Wikipedii

Badanie przeprowadzone na Wichita State University wykazało, że CPL miało jedynie niewielki wpływ na czytelność, w tym czynniki szybkości i zrozumienia. Zapytany o preferencje 60% respondentów wskazało jednak preferencję dla najkrótszej (35 CPL) lub najdłuższej (95 CPL) linii użytej w badaniu. Jednocześnie 100% respondentów wybrało jedną z tych wielkości jako najmniej pożądaną.

Sułtan
źródło
4
Nie, limit zdecydowanie nie powinien zostać zwiększony. Ponieważ nie ma to absolutnie nic wspólnego z technologią sitodruku i drukowania, jedynie fakt, że 80 znaków w wierszu dotyczy maksymalnej liczby, jaką ludzkie oczy mogą wygodnie skanować (66 znaków uważa się za optymalną szerokość linii, mniej w druku wielokolumnowym). Co zresztą oznacza, że ​​większość książek ma nieco mniej niż 80 kolumn na próbki kodu.
Jan Hudec
3
@JanHudec Ma wszystko do technologii sitodruku. Patrz programmers.stackexchange.com/questions/148677/... . Decyzja o przyjęciu 80 postaci jest czysto historyczna i nie oparta na badaniach. Czy możesz dodać linki do badań, aby potwierdzić swoją opinię?
Sulthan
Kolejne pytanie już zawiera ten link UX w jego komentarzach; dalsze odniesienia tam. Chociaż sama liczba 80 jest historycznym zbiegiem okoliczności, w przybliżeniu pochodzi ona od liczby uderzeń na linię na maszynie do pisania, która została z grubsza uzyskana ze wspólnej szerokości druku jednokolumnowego, a średnia 66 liter była długą tradycją.
Jan Hudec