Badania nad optymalną szerokością kodu?

134

Jeśli włączysz opcję „View Right Margin” (Wyświetl prawy margines) w wybranym IDE, prawdopodobnie będzie ona zawierać domyślnie 80 znaków. Zwykle zmieniam go na 120 bez powodu, poza tym, że był to standard w firmie, w której pracowałem kilka lat temu, i żadna inna firma nie powiedziała mi, żebym robił to inaczej.

Moje pytanie brzmi: czy są jakieś badania, które faktycznie pokazują 80 znaków jako optymalną maksymalną szerokość dla czytelności kodu, czy też ta wartość jest po prostu „tak było zawsze” i nikt tak naprawdę nie wie, dlaczego tak jest? I czy szerokość linii kodu powinna być częścią twojego standardu kodowania?

code-readability 
— Fostah
źródło
1
Chociaż nie znam żadnych badań, znajdziesz wiele opinii jako odpowiedzi na to pytanie: * Czy istnieje ważny powód, aby narzucić maksymalną szerokość 80 znaków w pliku kodu w dzisiejszych czasach?
— Adam Bellaire
3
żadnych badań, o których wiem, ale może być interesujące przyjrzenie się różnym standardom kodowania projektów. Na przykład Google ma 80 znaków. ( code.google.com/p/google-styleguide ) gdzie jako WebKit (ala Apple?) nie ma limitu AFAIK ( webkit.org/coding/coding-style.html ). Wydaje się, że Mozilla ma 80 lat ( developer.mozilla.org/En/Mozilla_Coding_Style_Guide#Line_length )
— gman
1
Jest to ten sam powód, dla którego piszemy „Biurokrata” w sposób, w jaki to robimy. Ponieważ dawno temu ktoś zdefiniował standard z powodu, który mógł mieć sens lub nie. Jeśli chodzi o pisownię, była to wątpliwa fascynacja łaciną, kodem wielkości papierowej karty dziurkowanej. Wtedy jedna metoda została oznaczona jako „poprawna”. Od tego czasu drobni biurokraci narzucają standardy.
— Tuntable

Odpowiedzi:

117

Właściwie to 80-kolumnowa rzecz długo poprzedza DOS. Pochodzi z dziurkaczy, które były urządzeniami 80-kolumnowymi.

Aby w pewnym sensie odpowiedzieć na pytanie PO, od około 600 lat trwa jedno „badanie” - książka drukowana. Te ewoluowały na przestrzeni wieków, mając na uwadze przede wszystkim czytelność, do stanu, w którym się obecnie znajdujemy, gdzie średnia długość linii tekstu wynosi około 60 znaków. Więc dla czytelności wybierz węższe marginesy.

85
Naprawdę nie wierzę, że pod względem użyteczności można porównać czytanie w języku naturalnym z czytaniem języka programowania.
— Frug
25
@Frug - właściwie prawdopodobnie możesz. Przyczyną szerokości 65 znaków nie jest to, że nie można odczytać większych linii, ale to, że łuk jest zbyt ciasny, gdy oko przechodzi do następnej linii. Możesz to obejść, zwiększając wysokość linii, ale to utrudnia użycie odstępów między blokami do przekazania znaczenia, więc prawdopodobnie jest to coś, czego należy unikać w środowisku IDE.
— Jimmy Breck-McKye,
32
@Jim - Mój język naturalny nie zawiera słów z 30 znakami (zresztą nie żebym ich używał) i analizuje się zupełnie inaczej niż język programowania. Często można zgrupować wiersz kodu jako oddzielny od reszty, czy to długi warunek, czy też kombinację długich metod i klas. Połączmy to z wcięciem, a porównanie obu języków stanie się absurdalne. Nie wątpię, że ktokolwiek naukowo badający czytelność i długość linii sprzeciwiłby się twojemu zmywaniu różnic.
— Frug
10
@Frug - tak naprawdę nie widzę, jak Twoje zastrzeżenia odnoszą się do któregokolwiek z moich twierdzeń, ale widzę, że wcięcie łamie proponowany przeze mnie model. Nie nazywaj mnie jednak „Jim”.
— Jimmy Breck-McKye
17
Książka jest zwykle umieszczona znacznie bliżej oczu niż monitor, co oznacza, że ​​mniej znaków w wierszu jest dozwolonych, jeśli czytelnik ma być w stanie czytać książkę bez konieczności wyciągania szyi. Ekran zwykle nie jest umieszczony w odległości od książki, co oznacza, że ​​można użyć większej liczby znaków w wierszu, nie przekraczając maksymalnego kąta widzenia. Ponadto kod nie jest czytany tak często, jak jest czytany, przez co ta szerokość jest mniej ważna. Ja (YMMV) mogę z łatwością śledzić linie zawierające 120 znaków kodu na ekranie mojego laptopa, ale to jest zbyt szerokie dla 2 buforów emacsa na moim 15
— calowym
109

Miej litość nad programistami, którzy będą musieli później zajmować się Twoim oprogramowaniem i trzymaj się limitu 80 znaków.

Powody, dla których warto preferować 80:

  • Czytelny z większą czcionką na laptopach

  • Pozostawia miejsce na zestawienie dwóch wersji obok siebie w celu porównania

  • Pozostawia miejsce na widoki nawigacji w IDE

  • Wydruki bez arbitralnie przerywanych linii (dotyczy również wiadomości e-mail, stron internetowych itp.)

  • Ogranicza złożoność w jednej linii

  • Ogranicza wcięcia, co z kolei ogranicza złożoność metod / funkcji

Tak, powinno to być częścią standardu kodowania.

— starblue
źródło
11
To świetne powody, aby zachować szerokość linii do 80 znaków lub mniej. Jestem naprawdę zaskoczony (rozczarowany), że Twoja odpowiedź, która jest wyraźnie przemyślana i poprawna, nie otrzymała więcej punktów. Do tej listy dodałbym: (1) przewijanie w poziomie nie jest zabawne. (2) Możesz znacznie zwiększyć gęstość kodu, nad którym pracujesz, wyświetlając ten kod w wielu kolumnach. Znaczna część nieruchomości marnuje się, gdy masz kilka linii, które rozciągają się daleko w prawo, podczas gdy większość innych linii nie.
— Donnie Cameron,
4
ok, ale co się dzieje, gdy jest blok kodu z kilkoma wcięciami? co mi się przydarzyło i 80 postaci wcale nie jest zabawnych.
— EKanadily
14
Limits the complexity in one lineNie jestem pewien, dlaczego rozłożenie złożoności na wiele linii jest lepsze. Po prostu wpycha więcej na twój mentalny stos.
— Jonathan,
4
To bardzo stary temat. ale czy nadal zgadzasz się, że wielu programistów używa 27-calowych monitorów :-). Mam na myśli, że jeśli problemem jest wzrok, może pomóc większy ekran. 8 lat temu nadal pracowaliśmy na monitorach 17 lub 20 cali, a niektóre nawet na rozdzielczościach 4: 3.
— Mathijs Segers
1
@MathijsSegers, niezależnie od rozmiaru lub rozdzielczości monitora, nadal wygodniej jest trzymać tekst w środkowych 30 stopniach pola widzenia. Podczas pracy z wieloma otwartymi oknami na monitorach obok siebie zwykle odwracam głowę, aby spojrzeć z jednego na drugie. Osoba nie powinna odwracać głowy ani obracać oczu do końca, aby móc czytać od jednego końca wiersza do drugiego. Tak duża rotacja oczu lub głowy prawdopodobnie spowodowałaby zawroty głowy, gdyby była wykonywana przez cały dzień.
— Maurice
41

Nie mam studiów, ale opowiem o swoim doświadczeniu.

Uważam, że przewijanie w poziomie jest uciążliwe podczas pracy z tekstem. Patrzę na środowisko, w którym będzie używany kod, i ustalam standardy szerokości w oparciu o ten kontekst.

Na przykład, kiedy pracowałem w Emacsie na XWindows, dobrze było mieć 2 okna Emacsa przez cały czas obok siebie . To ograniczyło ich do 80 znaków, więc taka była moja maksymalna długość linii.

W pewnym momencie pracowałem w Visual Studio na ekranie 1920x1200. Utrzymałbym go zmaksymalizowanym, ze wszystkimi oknami narzędzi zadokowanymi z jednej strony. Zostało wystarczająco dużo miejsca na dwa okna edytora obok siebie po około 100 znaków.

Uważam również, że najdłuższe wiersze pochodzą z wywołań metod z długimi listami parametrów . Czasami jest to zapach kodu : być może metoda powinna zostać refaktoryzowana .

Jeśli Ty i Twoi współpracownicy macie ekrany o wysokiej rozdzielczości i bystry wzrok, koniecznie używajcie małej czcionki i długich linii. I odwrotnie, możesz potrzebować krótkich linii.

— Jay Bazuzi
źródło
1
plus jeden za „bystre oczy”, bo tak naprawdę to się ze mną stało.
— EKanadily
26

Zwykle używam 120-150, chyba że firma określi inaczej. Zależy to jednak również od rodzaju kodu:

  • Ja (prawie) nigdy nie używam wielu instrukcji w jednej linii
  • Używam długich linii (> 12) tylko wtedy, gdy wiersze, które wyglądają podobnie, można wyrównać, a nie złamać.
  • Zawsze używam wystarczającej ilości spacji / nawiasów itp
  • Wolę dłuższe nazwy zmiennych niż nazwy krótsze

Jeszcze kilka lat temu ograniczyłem się do 100, ale teraz zwykle używa się panoramicznych ekranów, a monitory o wysokiej rozdzielczości 120 można nawet zobaczyć na laptopach (z których prawie nie korzystam).

Porównanie ekranu z książką nie jest dobre, ponieważ książka ma więcej przestrzeni w pionie, a ekran ma więcej przestrzeni w poziomie. Zawsze staram się, aby funkcja była max. jeden widoczny ekran.

— Michel Keijzers
źródło
6
Jak działa 120-150 znaków w linii przy jednoczesnym otwarciu wielu okien obok siebie? Czy wiele okien edytora kodu jest otwartych obok siebie? - Na moim 30-calowym monitorze mogę mieć 3 okna obok siebie, jeśli ograniczę linie do 97 znaków / linię.
— KajMagnus
1
Koduję na dużym wyświetlaczu i lubię też większe kwoty. Celuję w 110-130. Jednym z moich głównych celów jest czytelność, a dzielenie wypowiedzi na 2-3 wiersze jest czasami mniej czytelne. Czasami też przechodzę do 500-1000, aby ukryć śmieci, których nie chcę widzieć, takie jak niektóre komentarze, wyłączony kod i niektóre wartości zakodowane na stałe. Myślę, że to też zależy od programisty. Jeśli większość programistów działa na 80, najlepiej dążyć do tego podczas pracy ze współdzielonym kodem.
— Sunsetquest
10

Być może 80 postaci to również dobry punkt, aby uniknąć tych złych łańcuchów getterów:

object.getFoo().getBar().getFooBar().get ...

jeśli ograniczysz to do 80 znaków, może ktoś zlokalizowałby te zmienne i sprawdziłby wartość null itp., ale może większość programistów pozwoliłaby im zawijać je w następnym wierszu. Nie wiem

Poza tym 80 postaci jest świetnych, jak wspomniano w Starblue. Powinno to zdecydowanie przejść do standardów kodowania.

— Christopher Klewes
źródło
5
FYI, takie nadmierne tworzenie łańcuchów jest znane jako przeciw wzorowi wraku pociągu .
— Dennis
5

Pomijając ograniczenia sprzętowe i wszelkie różnice w sposobie odczytywania kodu w porównaniu z językiem naturalnym, widzę trzy główne powody, dla których należy ograniczyć wiersze do około 80 znaków.

  1. Ludzkie gałki oczne są okrągłe, niezbyt wąskie i szerokie, a większość ich rozdzielczości znajduje się pośrodku . Podczas czytania godzinami o wiele wygodniej jest przesuwać oczy krótkimi łukami, używając w razie potrzeby jednego paska przewijania. Nie znam formalnego badania dotyczącego czytelności kodu, ale z moich własnych obserwacji, przy monitorze oddalonym o 2 stopy, z tekstem o rozmiarze czcionki o stałej szerokości 10 punktów, 100 znaków zajmuje około 1/3 mojego pola poziomego widzenia, czyli około 60 stopni ( poza około 30 stopniami, gdzie rozdzielczość wszystkich naszych oczu jest na poziomie ).
  2. Większość ludzi korzysta w pracy z dużego monitora, aby widzieć wiele rzeczy bez klikania w tę i z powrotem, a nie po to, aby zobaczyć jedną naprawdę dużą rzecz.
  3. Krótsze linie mają mniejszą złożoność, co, miejmy nadzieję, zmusza programistę do podzielenia kodu na łatwiejsze do przyswojenia jednostki.
— Maurice
źródło
3

Wyraźnie pamiętam, że gdzieś czytałem (myślę, że było to w Dokumentacji Agile ), że dla optymalnej czytelności szerokość dokumentu powinna wynosić około dwóch alfabetów lub 60-70 znaków. Myślę, że szerokość linii starych terminali pochodziła częściowo z tej starej reguły typograficznej.

— lindelof
źródło
3

Opcja prawego marginesu ma na celu pokazanie szerokości strony, jeśli zamierzasz wydrukować kod, a wcześniej opublikowałeś informację, że jest ustawiona na 80, ponieważ taka była historycznie długość linii przed GUI, aż do punch karty.

Widziałem ostatnio na pewnym blogu zalecenie (nie pamiętam, który blog), aby zwiększyć rozmiar czcionki IDE w celu poprawy jakości kodu, logika jest taka, że ​​jeśli mniej kodu mieści się na ekranie, napiszesz krótsze linie i funkcje shouter.

Moim zdaniem krótsze linie ułatwiają czytanie kodu i debugowanie, więc staram się, aby linie były krótkie, jeśli musisz ustawić limit, aby napisać lepszy kod, wybierz to, co działa dla Ciebie - również jeśli jesteś bardziej produktywny z dłuższe linie zachęcają do zwiększenia rozmiaru strony i kodu tylko na szerokich ekranach.

— Nir
źródło
0

O ile mi wiadomo, 80 znaków jest używany jako standard kodowania w celu zachowania zgodności z edytorami wiersza poleceń (domyślna szerokość terminala to zwykle 80 znaków). Przy nowoczesnych IDE i dużych rozdzielczościach ekranu 80 znaków prawdopodobnie nie jest „optymalne”, ale dla wielu programistów utrzymanie czytelności terminala jest niezbędne. Z tego powodu jest mało prawdopodobne, aby szerokość 80 znaków została w najbliższym czasie zastąpiona de facto standardem szerokości kodu. Aby odpowiedzieć na ostatnie pytanie, tak, szerokość kodu, a także wszelkie inne cechy, które wpłyną na czytelność kodu, powinny być uwzględnione w standardach kodowania.

0

Jak niektórzy ludzie zauważyli w innych odpowiedziach, powód ograniczenia 80 znaków jest częściowo historyczny (karty dziurkowane, małe ekrany, drukarki itp.), A częściowo biologiczny (aby śledzić, w której linii się znajdujesz, ogólnie dobrze jest widzieć cały bez konieczności obracania głowy).

To powiedziawszy, pamiętaj, że nadal jesteśmy ludźmi i tworzymy narzędzia, aby rozwiązywać własne ograniczenia. Proponuję zignorować całą debatę na temat ograniczeń znaków i po prostu napisać rzeczy, które mają sens niezależnie od ich długości, i użyć IDE lub edytora tekstu, który pomoże ci prawidłowo śledzić linie. Używając tego samego argumentu dla wcięć w debacie tabs vs spacje, a także jak szerokie powinny być wcięcia, proponuję użyć znacznika wcięcia (najczęściej tabulatora) i po prostu poprosić ludzi o skonfigurowanie własnego IDE lub edytorów tekstu, aby je wyświetlić tak, jak im najbardziej odpowiada.

Trzymanie się ustalonej liczby znaków w linii zawsze pogorszy sytuację dla wszystkich poza grupą docelową. To powiedziawszy, jeśli nigdy nie udostępnisz kodu, nigdy; to naprawdę nie ma powodu, aby w ogóle rozpocząć tę dyskusję. Jeśli chcesz udostępnić kod, prawdopodobnie powinieneś pozwolić ludziom samodzielnie decydować, czego chcą, zamiast narzucać im swoje (lub kogoś innego) ideały.

— Jonas Lihnell
źródło
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.