Dlaczego PEP-8 określa maksymalną długość wiersza 79 znaków? [Zamknięte]

235

Dlaczego w tym tysiącleciu Python PEP-8 powinien określać maksymalną długość wiersza 79 znaków?

Prawie każdy edytor kodu pod słońcem może obsługiwać dłuższe linie. To, co należy zrobić z opakowaniem, powinno być wyborem konsumenta treści, a nie odpowiedzialnością twórcy treści.

Czy istnieją (uzasadnione) dobre powody, by stosować 79 znaków w tym wieku?

python pep8

— pcorcoran
źródło

73

Odpowiedź na twoje pytanie znajduje się w PEP-8.

— cdleary

29

Krótsze długości linii zwiększają wydajność poprzez zwiększenie KLOC. : p

— Alex

26

Limit 79 znaków jest całkowicie nieaktualny. Każda skromnie złożona baza kodu pokazuje, jak sprawia, że kod jest znacznie trudniejszy do czytania. Np .: github.com/openstack/nova/blob/master/nova/network/manager.py

— Jonathan

6

@Jonathan: dla mnie wygląda dobrze ...

— nperson325681,

9

Czy wy ludzie nie używacie równoległych narzędzi różnicowych?

— endolith,

129

Dużą wartością PEP-8 jest powstrzymanie ludzi od kłótni o niekonsekwentne reguły formatowania i rozpoczęcie pisania dobrego, konsekwentnie sformatowanego kodu. Jasne, nikt tak naprawdę nie uważa, że 79 jest optymalne, ale nie ma oczywistych korzyści ze zmiany go na 99 lub 119 lub inną preferowaną długość linii. Myślę, że wybory są następujące: przestrzegaj zasady i znajdź wartościowy powód do walki lub podaj dane, które pokazują, jak czytelność i wydajność różnią się w zależności od długości linii. Ten ostatni byłby niezwykle interesujący i miałbym duże szanse na zmianę zdania ludzi.

28

Większość badań dotyczących czytania odbywa się w calach, a nie w znakach w wierszu. Reguła 66 znaków opiera się na badaniach przeprowadzonych w celu czytania gazet. Ostatnie badania wykazały, że podczas czytania artykułów online szybkość czytania wzrasta do około 120 znaków w wierszu (10 cali przy rozmiarze czcionki 12) bez utraty zrozumienia.

— Tempo

7

Właściwie wszyscy, którzy czytają ten temat, uważają, że 79 znaków jest optymalnych. Właśnie dlatego został dodany do PEP8! Ta odpowiedź jest w rzeczywistości błędna. Ten jest poprawny

— erikbwork

6

Myślałem, że pytanie dotyczy tego, dlaczego 79 jest lepsze niż 80 lub 78

— n611x007,

157

there's no obvious gain in changing it to 99 or 119 or whatever your preferred line length is Jest to tak źle na wiele sposobów. Zawiń wiersz o 40 znaków i powiedz, jak jest czytelny. Oczywiście mniej zawijania = większa czytelność, o ile masz miejsce na ekranie, co robisz w 2015 roku. Owijanie wpływa na czytelność. Czytelność wpływa na łatwość konserwacji. Utrzymywalność wpływa na jakość. Jakość wpływa na jakość 80 znaków. Kropka.

— Jonathan

6

Argumentowanie o czytelności w przypadku elementów innych niż kod jest bezużyteczne, ponieważ badania te zakładają wyświetlanie tekstu. Kod wygląda zupełnie inaczej z różną długością (znakową) każdej linii. I nawet jeśli piszesz do końca linii, wcięcie zmienia liczbę znaków w linii.

— Corvince,

111

Zapewnienie czytelności kodu nie tylko maszynowi. Wiele urządzeń może jednocześnie wyświetlać tylko 80 znaków. Ułatwia także wielozadaniowym osobom z większymi ekranami możliwość ustawiania wielu okien obok siebie.

Czytelność jest również jednym z powodów wymuszonego wcięcia linii.

— Justin Bozonier
źródło

58

Tak, przyznano. Ale dlaczego 79? Dlaczego nie 100 lub 120? Utrzymywanie czytelności działa w obie strony. Zbyt trudno jest też odczytać zbyt dużo w górę i w dół kodu.

— pcorcoran

17

To prawda, że wiele urządzeń może wyświetlać tylko 80 znaków. Ilu z nich nie może wykonać owijania miękkiego?

— Jim

39

Ponadto zaleca się, aby nie było zawijania kodu. Z punktu widzenia doświadczenia użytkownika jest to nie do przyjęcia dla większości.

— Justin Bozonier

8

Istnieje kilka systemów operacyjnych, takich jak MVS, które nie obsługują linii dłuższych niż 72 znaki. PEP-8 tutaj nie pomoże. Ustawienie arbitralnego limitu 79 znaków nie ma sensu, ponieważ to, jak dobre są znaki w wierszu, zależy od edytora, monitora, osobistych preferencji użytkownika i tak dalej.

— codymanix

96

79 znaków powoduje również, że programiści używają krótszych, bardziej tajemniczych nazw zmiennych i funkcji, aby wszystko dopasować. Jest to niekorzystne dla czytelności.

— Gert Steyn,

46

Jestem programistą, który codziennie ma do czynienia z dużą ilością kodu. Open source i to, co zostało opracowane we własnym zakresie.

Jako programista uważam za przydatne, aby jednocześnie otwierać wiele plików źródłowych i często organizować pulpit na monitorze (panoramicznym), aby dwa pliki źródłowe były obok siebie. Mogę programować w obu lub tylko czytać i programować w drugim.

Uważam, że jest to niezadowalające i frustrujące, gdy jeden z tych plików źródłowych ma> 120 znaków szerokości, ponieważ oznacza to, że nie mogę wygodnie dopasować linii kodu na linii ekranu. To zaburza formatowanie do zawijania linii.

Mówię „120”, ponieważ jest to poziom, do którego denerwowałbym się, że kod jest szerszy niż. Po tylu znakach powinieneś rozdzielać wiersze dla zapewnienia czytelności, nie mówiąc już o standardach kodowania.

Piszę kod z myślą o 80 kolumnach. Jest tak po prostu, że kiedy przeciekam przez tę granicę, nie jest to taka zła rzecz.

— Jerub
źródło

11

„Piszę kod z myślą o 80 kolumnach. To dlatego, że kiedy przeciekam przez tę granicę, nie jest to takie złe”. Dla mnie to samo.

— KobeJohn

4

10 lat później: czy to nie zależy tylko od konfiguracji owijania linii. Owijanie linii może być tak inteligentne lub głupie, jak chcesz. Jeśli czytanie jest niewygodne, oznacza to tylko awarię edytora.

— David Mulder,

2

Koduję do 120 znaków, ale czasami dłuższe, gdy odpowiada to czytelności. Czarne formaty na 120, jeśli tak mówisz. PEP-8 mówi także: „Można zwiększyć limit długości linii do 99 znaków”, ale ludzie zdają się tłumić tę informację przez większość czasu. Prawie nikt nie używa terminali o szerokości 80. Wiadomości dziennika nigdy nie mają szerokości 80.

— NeilG

37

Wierzę, że ci, którzy studiują typografię, powiedzą ci, że 66 znaków w linii ma być najbardziej czytelną długością. Mimo to, jeśli potrzebujesz zdalnie debugować maszynę podczas sesji ssh, większość terminali ma domyślnie 80 znaków, 79 po prostu pasuje, próba pracy z czymkolwiek szerszym staje się w takim przypadku prawdziwym bólem. Zaskoczy Cię również liczba programistów używających vim + screen jako codziennego środowiska.

— Sean O Donnell
źródło

<flame> Emacs FTW! </flame> +1. Myślę, że limit 79 pochodzi z początków UNIX (i prawdopodobnie MULTICS), które miały terminale znaków 80x25.

— Joe D

10

Moje środowiska ssh + screen + vim nie mają problemu z wyświetlaniem długich linii.

— chrishiestand

54

„66 znaków w wierszu ma być najbardziej czytelną szerokością długości”. Przypuszczam, że powinniśmy pisać kod w 2 lub 3 kolumnach, skoro tak wyglądają gazety?

— Mark E. Haase,

23

@mehaase: twoja sarkastyczna uwaga jest bardzo zbliżona do prawdy: porządni redaktorzy mogą robić podzielone panele i pokazywać różne rzeczy obok siebie (z tych samych lub różnych plików). Przypadkowo jest to zwykle możliwe tylko wtedy, gdy kod ma standard długości linii ...

— nperson325681,

2

@mehaase: Właściwie brzmi świetnie. Nie żartuję.

— Teekin

19

Drukowanie czcionki o stałej szerokości w domyślnych rozmiarach to (na papierze A4) 80 kolumn na 66 linii.

— Josh
źródło

11

Akceptuję ten standard; jest ważny. Ale kto już drukuje kod? Ponadto, kto drukuje kod ze środowiska, które nie toleruje skalowania lub innych opcji formatowania? Kiedy ostatni raz ktoś, kogo znasz, był zakłopotany niemożnością renderowania linii 100 znaków?

— pcorcoran

3

Dlaczego ludzie drukują kod w 2012 roku? Przypomina mi to pójście na konferencję technologiczną i wręczenie torby i wydrukowanego segregatora pełnego prezentacji. To ludzie XXI wieku: wyślij mi e-mailem slajdy, albo torba i segregator idą prosto na wysypisko śmieci.

— Mark E. Haase,

2

więc dlaczego 80-1 jest lepszy niż 80-0 lub 80-2?

— n611x007,

11

„w domyślnych rozmiarach” Mówisz? Powiedz mi więcej o tych powszechnie akceptowanych rozmiarach domyślnych.

— Bruno Bronosky,

15

Tak, nadajmy priorytetowi wygląd kodu na drukowanym papierze ponad wszystko.

— Jonathan

8

Oto dlaczego podoba mi się ten 80-znakowy: w pracy używam Vima i pracuję nad dwoma plikami na monitorze działającym, jak sądzę, w rozdzielczości 1680x1040 (nigdy nie pamiętam). Jeśli linie są już dłuższe, mam problem z odczytaniem plików, nawet podczas używania zawijania słów. Nie trzeba dodawać, że nienawidzę zajmować się kodem innych ludzi, ponieważ uwielbiają długie linie.

nie używasz również vima dla javascript / html?

— elad srebrny

2

@eladsilver Nie mogę wypracować, czy to żart? :-D

— Steven Church

przepraszam, niezbyt dogłębnie z vimem, oczywiście jeśli pracujesz w sieci, używasz go również do html / js i te typy nigdy nie mają limitu 80 znaków, ponieważ programiści frontowi nie wiedzą o pep8, więc ustawienie Pythona na 80 znaków nie rozwiąże problemu, jeśli użyjesz więcej niż tylko python. więc pytam, jak radzisz sobie z innymi językami programowania?

— elad srebrny

Pracuję w Vimie ze 120 liniami znaków. Używam: diffthis z podziałem poziomym. Jeśli zmieścisz tylko 160 znaków na 1680 pikselach, musisz mieć duży rozmiar czcionki.

— NeilG

4

Ponieważ białe znaki mają znaczenie semantyczne w Pythonie, niektóre metody zawijania słów mogą dawać niepoprawne lub niejednoznaczne wyniki, więc należy wprowadzić pewien limit, aby uniknąć takich sytuacji. Długość linii 80 znaków jest standardowa, odkąd korzystaliśmy z teletypów, więc 79 znaków wydaje się dość bezpiecznym wyborem.

— Chris Upchurch
źródło

4

Istnieją dwa różne rodzaje zawijania słów. Jest zawijanie na twardo, gdzie linie są dzielone na nowe linie, i jest miękkie zawijanie, gdzie są wyświetlane tylko z przerwami, ale fizycznie pozostają pojedynczą linią. Nie widzę z tym żadnego problemu.

— Jim

4

Większość edytorów Pythona nie zawija miękkich słów, ponieważ tworzy niejednoznaczny, trudny do odczytania kod w języku, w którym spacje i wcięcia są ważne.

— Chris Upchurch,

4

Nie generuje dwuznacznego ani trudnego do odczytania kodu, o ile opakowanie jest w jakiś sposób wizualnie identyfikowane. Kate to robi i działa dobrze. Jeśli redaktor nie poradzi sobie z tym, to jest powód zgłoszenia błędu przeciwko edytorowi, a nie powód narzucenia stylu kodowania, który pozwala uniknąć błędu.

— Jim

5

Nawet jeśli jest to wskazane wizualnie, nadal sprawia, że kod jest znacznie trudniejszy do odczytania, dlatego edytory Python na ogół go nie obsługują.

— Chris Upchurch,

Czy próbowałeś tego przez dłuższy czas? Mam. Z mojego doświadczenia nie czyni to trudniejszym do odczytania. Czy możesz uzasadnić twierdzenie, że właśnie dlatego edytory Python nie zawierają tej funkcji? Nigdy wcześniej nie słyszałem tego roszczenia.

— Jim

1

Zgadzam się z Justinem. Opracowując, zbyt długie wiersze kodu są trudniejsze do odczytania przez ludzi, a niektórzy ludzie mogą mieć konsolowe szerokości, które mieszczą tylko 80 znaków w wierszu.

Zalecenia dotyczące stylu mają na celu zapewnienie, że napisany kod może być odczytany przez jak najwięcej osób na możliwie największej liczbie platform i tak wygodnie, jak to możliwe.

— Tylko czytać
źródło

10

To leniwy argument. Nie zawsze 80 linii szkodzi czytelności. Szybkie spojrzenie na skromnie złożoną bazę kodu Pythona, która zawija się w 80 liniach, faktycznie pokazuje coś przeciwnego - owijanie wywołań funkcji pojedynczej linii do kilku linii utrudnia śledzenie WTF.

— Jonathan

0

ponieważ jeśli wypchniesz go poza 80. kolumnę, oznacza to, że albo piszesz bardzo długi i skomplikowany wiersz kodu, który robi zbyt wiele (i dlatego powinieneś zrefaktoryzować), lub że wciąłeś zbyt dużo (a więc powinieneś refaktoryzować).

— Stefano Borini
źródło

90

-1, nie sądzę, aby można kategorycznie powiedzieć, że każda linia poza granicą 80 znaków wymaga refaktora. Metody klasowe są już dwa razy wcięte, dodaj kolejne wcięcie dla „if” itp. Oraz proste zrozumienie listy, i dość łatwo jest przekroczyć granicę 80 znaków.

42

Nie wspominając już o tym, że jeśli nazwiesz symbole w taki sposób, aby były czytelne dla człowieka, np. „Users_directed_graph” zamiast „usr_dir_gph”, to nawet prosty wyraz zużyje sporo znaków w wierszu.

— Mark E. Haase,

8

W Pythonie zawsze znajdowałem, że jeśli przekroczę 80 znaków, mądrze jest przestać i zastanowić się, dlaczego tak jest. Zwykle wina leży po złej decyzji projektowej.

— Mike Vella,

3

Takie też było moje doświadczenie. Adresuje także dłuższe nazwy zmiennych, jak wskazuje @mehaase, ale myślę, że jest to korzyść. Dostępne kombinacje trzech następujących po sobie słów (w przypadku „users_directed_graph”) przewyższają liczbę komponentów, które rozsądnie mieszczą się w pojedynczej przestrzeni nazw. Uważam, że starszy kod, który napisałem, w którym wiele podobnych długich nazw zmiennych znajduje się w tej samej przestrzeni nazw, jest trudniejszy do odczytania i ogólnie lepszy do refaktoryzacji.

— TimClifford,

4

W języku wymagającym wcięć dla każdej zmiany zakresu, stwierdzenie, że 80 linii znaków odpowiada złożoności, jest zbyt uproszczonym argumentem. Czasami wystarczy 80 znaków, aby wywołać funkcję. Współczesne edytory / edytory IDE dla innych języków są wystarczająco inteligentne, aby to rozpoznać i potrafią rozpoznać, kiedy należy owijać, zamiast nakładać ogólne ograniczenia na wszystko, co ogólnie szkodzi czytelności.

— Jonathan