Czy istnieje uzasadniony powód, aby wymusić maksymalną szerokość 80 znaków w pliku kodu w tym dniu i wieku? [Zamknięte]

159

Poważnie. Na 22-calowym monitorze zajmuje tylko jedną czwartą ekranu. Potrzebuję trochę amunicji, aby zniwelować tę zasadę.


Nie mówię, że nie powinno być ograniczeń; Mówię tylko, że 80 znaków to bardzo małe.

TraumaPony
źródło
Wszystkie odpowiedzi w zasadzie określają to, co chciałem dodać. Podam przykład z życia wzięty - mam x61s, rozdzielczość 1024x768. Kiedy jestem w drodze, nie mam swojego wymyślnego monitora. Otwieranie kodu w moim IDE jest uciążliwe, gdy przekracza tę regułę.
Do
Nawet jeśli masz zestaw 3 monitorów. To nie jest powód do kręcenia głową od prawej do lewej iz powrotem. Na zawsze. Ah-ha-ha. W rzeczywistości oko porusza się szybciej niż głowa. Czy wiesz o felietonach w gazetach? Powodem szerokości jest wygoda oka / głowy / mężczyzny.
Ivan Black

Odpowiedzi:

257

Myślę, że praktyka utrzymywania kodu w 80 (lub 79) kolumnach została pierwotnie stworzona, aby wspierać ludzi edytujących kod na 80-kolumnowych głupich terminalach lub na 80-kolumnowych wydrukach. Te wymagania w większości zniknęły, ale nadal istnieją ważne powody, aby zachować zasadę 80 kolumn:

  • Aby uniknąć zawijania podczas kopiowania kodu do wiadomości e-mail, stron internetowych i książek.
  • Aby wyświetlić wiele okien źródłowych obok siebie lub za pomocą przeglądarki różnic obok siebie.
  • Aby poprawić czytelność. Wąski kod można szybko odczytać bez konieczności skanowania oczu z boku na bok.

Myślę, że ostatni punkt jest najważniejszy. Chociaż wyświetlacze wzrosły pod względem wielkości i rozdzielczości w ciągu ostatnich kilku lat, oczy nie .

Will Harris
źródło
7
Być może „w dużej mierze odeszli”, ale nie całkowicie. Zwykle pracuję z dwoma różnymi konfiguracjami: 1) w oknie ssh podłączonym do zdalnego komputera. który ma domyślnie 80 znaków szerokości. i 2) W programie Visual Studio, z dwoma panelami obok siebie, dzięki czemu mogę jednocześnie widzieć nagłówek i plik cpp.
Enno
10
@steffenj: Właściwie, książki wydają się strzelać do około 66 znaków w linii (choć różni się nieco w zależności od innych parametrów), ponieważ dłuższe linie zrobić make czytanie trudniejsze. Można się spierać o maksymalną długość linii kodu , ale 80 jest wygodne ze względów historycznych i praktycznych.
Steve S
69
Problem polega na tym, że zmuszając ludzi do utrzymywania krótkich długości linii, zwykle używają mniej znaczących nazw.
Ian Ringrose,
4
Uważam, że uwagi na temat czytelności są dość interesujące, ponieważ to, czego naprawdę nienawidzę w drukowanych artykułach / książkach / ... programowaniu, jest takie, że krótkie wiersze, które są używane w przykładach kodu, są niezwykle trudne do odczytania. Przeniesienie czegoś do nowego wiersza może mieć sens, ale grupowanie powinno przebiegać logicznie, rekursywnie rozcinając wyrażenie, a nie dlatego, że urządzenie wyjściowe przypadkowo osiągnęło swoje ograniczenie. IOW, uważam, że urządzenia, które narzucają tak wąskie ograniczenia, nie są dobrze przystosowane do wyświetlania kodu.
Chris Lercher,
4
Myślę, że problem z 80-kolumnowymi programami egzekwującymi polega na tym, że zapominają, że zamiast tego kod rośnie w kierunku pionowym. Masz ten sam problem, ale w kierunku pionowym ORAZ na górze tego nowoczesnego kodu wygląda okropnie, gdy musisz łamać pojedyncze instrukcje w dwóch, a czasem nawet w czterech lub pięciu wierszach. NIE jest bardziej czytelny. We współczesnym kodzie mam na myśli opisowe nazwy zmiennych i kwalifikujące się dziedziczenie, przestrzenie nazw, klasy itp. Prosimy o zatrzymanie 80-kolumnowych bez słów, zamiast tego kieruj się zdrowym rozsądkiem. 120 jest lepsze, ale też nie powinno być regułą.
Larswad
79

Pochodzenie 80-kolumnowego formatowania tekstu jest wcześniejsze niż 80-kolumnowe terminale - karta dziurkowana IBM sięga 1928 roku ! Przypomina to (apokryficzną) opowieść, że tory kolejowe w Stanach Zjednoczonych były określane przez szerokość kół rydwanów w rzymskiej Brytanii.

Czasami wydaje mi się to trochę zawężające, ale warto mieć jakieś standardowe ograniczenie, więc jest to 80 kolumn.

Oto ten sam temat omówiony przez Slashdot .

A oto oldschoolowe oświadczenie w języku Fortran:

Karta perforowana FORTRAN

Johna Cartera
źródło
60

80 znaków to obecnie absurdalny limit. Podziel linie kodu tam, gdzie ma to sens, a nie według dowolnego limitu znaków.

Craig Day
źródło
Limit znaków nie mówi ci, GDZIE musisz podzielić linię kodu, ale KIEDY
gztomas
Nie, nie jest. Jeśli napiszesz dłuższą niż 80 znaków linię, prawdopodobnie masz już problem ze złożonością wyrażeń lub strategią nazewnictwa. Jak wspominali inni, czytelność jest głównym problemem, a prędkość czytania zaczyna spadać powyżej 60-66 znaków (typografia oparta na fizjologii człowieka).
sola
@sola Twój komentarz pojawia się tutaj z 98 znakami i jest to gęsty naturalny język obcy (dla mnie) do zrozumienia. Całkowicie czytelne. Kod z wcięciami do 3-4, znacznikami składni itp. Jest jeszcze łatwiejszy.
viyps
Przypadkowo odrzuciłem tę odpowiedź i nie mogę jej już głosować. :(
Andy
35

Powinieneś to zrobić ze względu na wszystkich, którzy nie mają 22-calowego monitora panoramicznego. Osobiście pracuję na 17-calowym monitorze 4: 3 i uważam, że jest on wystarczająco szeroki. Jednak mam też 3 takie monitory, więc nadal mam dużo miejsca na ekranie.

Nie tylko to, ale ludzkie oko ma problemy z odczytaniem tekstu, jeśli linie są zbyt długie. Zbyt łatwo się zgubić, w której linii się znajdujesz. Gazety mają 17 cali średnicy (lub coś podobnego), ale nie widzisz ich piszących na całej stronie, to samo dotyczy czasopism i innych drukowanych artykułów. W rzeczywistości jest to łatwiejsze do odczytania, jeśli kolumny będą wąskie.

Kibbee
źródło
14
Nie, gdy dodasz wcięcia do miksu. Jeśli używasz 4 spacji na wcięcie i znajdujesz się w czymś takim jak przestrzeń nazw-> klasa-> metoda-> if-> for, to 1/5 twojej spacji przepadła.
TraumaPony,
Zawsze możesz ustawić regułę na 80 znaków od wcięcia. W ten sposób oko może go łatwo śledzić.
Vincent McNabb
Czasami (ale nie zawsze) chciałbym, żeby .Net miał automatyczną przestrzeń nazw, żebyś nie musiał definiować przestrzeni nazw w pliku. To poważnie zakłóca wyrównanie twojego kodu. jeśli chcesz zagnieżdżonych przestrzeni nazw, masz naprawdę duże problemy.
Kibbee,
13
Jednak czytanie prozy to nie to samo, co czytanie kodu.
Atario
3
+1 dla gazet, świetny przykład. @Atario, czytanie DOBREGO kodu jest bardzo podobne do czytania prozy.
Todd Chaffee
23

W przypadku sekwencji instrukcji, które powtarzają się z niewielkimi zmianami, łatwiej będzie dostrzec podobieństwa i różnice, jeśli zostaną one pogrupowane w wiersze, tak aby różnice były wyrównane w pionie.

Twierdzę, że poniższy tekst jest o wiele bardziej czytelny, niż byłby, gdybym podzielił go na wiele wierszy:

switch(Type) {
case External_BL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_BR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_TR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case External_TL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_TR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case Internal_TL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
}

Aktualizacja: w komentarzu zasugerowano, że byłby to bardziej zwięzły sposób wykonania powyższego:

switch(Type) {
  case External_BL: dxDir = - 1; dyDir = - 1; break;
  case External_BR: dxDir = + 1; dyDir = - 1; break;
  case External_TR: dxDir = + 1; dyDir = + 1; break;
  case External_TL: dxDir = - 1; dyDir = + 1; break;
  case Internal_BL: dxDir = + 1; dyDir = + 1; break;
  case Internal_BR: dxDir = - 1; dyDir = + 1; break;
  case Internal_TR: dxDir = - 1; dyDir = - 1; break;
  case Internal_TL: dxDir = + 1; dyDir = - 1; break;
}
mpstrd["X"] = pt1.x + dxDir * RadialClrX;
mpstrd["Y"] = pt1.y + dyDir * RadialClrY; 

chociaż teraz mieści się w 80 kolumnach, myślę, że mój punkt widzenia jest nadal aktualny i właśnie wybrałem zły przykład. Nadal pokazuje, że umieszczenie wielu instrukcji w jednej linii może poprawić czytelność.

Sam Hasler
źródło
8
Mówiąc, że są tylko małe różnice między wierszami, mówisz również, że jest dużo nadmiarowego kodu. Usunięcie części z nich może znacznie zmniejszyć liczbę kolumn i nadal być wyrównane w pionie.
foraidt
@mxp: uzgodniono. Jeśli istnieje bardziej zwięzły sposób zapisania powyższego, byłbym zainteresowany, aby to zobaczyć.
Sam Hasler,
Zgadzam się z ogólną ideą, ale przykład ... A co z tego: switch (...) {case ... BL: dxDir = - 1; dyDir = - 1; przerwa; przypadek ... BR: dxDir = + 1; dyDir = - 1; przerwa; ...} ... ["X"] = pt1.x + dxDir * Rad ... X; ... ["Y"] = pt1.y + dyDir * Rad ... Y;
Yarik
38
Fakt, że muszę przewinąć pierwszy z dwóch przykładów poziomo, dowodzi, że krótsze linie są lepsze :-)
Enno
1
Nie rozumiem nienawiści do przewijania? To powszechna opinia i nie mówię, że jest błędna, po prostu jej nie rozumiem. Zwłaszcza jeśli jesteś w edytorze kodu, nie musisz nawet odsuwać rąk od klawiatury, aby dostać się do myszy - po prostu (ctrl+)arrownad lub naciśnijend
KOGI
21

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

Josh
źródło
16

Korzystam z zalet większych ekranów, aby mieć wiele fragmentów kodu obok siebie.

Nie dostaniesz ode mnie amunicji. W rzeczywistości nie chciałbym zobaczyć, jak to się zmieniło, ponieważ w nagłych wypadkach wciąż widzę rzadkie przypadki, w których muszę zmienić kod z konsoli tekstowej.

Twan
źródło
14

Bardzo długie wiersze są trudniejsze do odczytania. Tylko dlatego, że na monitorze można wyświetlić 300 znaków, nie oznacza to, że linie powinny być tak długie. 300 znaków jest również zbyt skomplikowane dla instrukcji, chyba że nie masz wyboru (wywołanie, które wymaga całej masy parametrów).

Zasadniczo używam 80 znaków, ale wyjdę poza to, jeśli wymuszenie tego oznaczałoby wstawienie końca wiersza w niepożądanym miejscu.

Loren Pechtel
źródło
Istnieją badania, które pokazują, że ludzie potrafią czytać i śledzić x liczbę znaków / słów, zanim stracą orientację. Myślę, że gdzieś tam jest 80. Nie mam jednak żadnych źródeł, które mogłyby to potwierdzić.
Do
Tak, myślę, że naprawdę nie chodzi o to, aby linie były krótkie, ale o to, by były one czyste / zwięzłe / czytelne / zrozumiałe.
KOGI,
Jeśli masz (wywołanie, które wymaga całej masy parametrów), i tak musisz przeprowadzić refaktoryzację.
Zarremgregarrok
@Zarremgregarrok Widziałem bardzo długie listy parametrów w interfejsach API firmy Microsoft.
Loren Pechtel
@LorenPechtel Czy to sprawia, że ​​jest dobrze napisany?
Zarremgregarrok
8

Jedyne, co wymuszam, aby pozostać w granicach 80 znaków, to mój komentarz.

Osobiście ... Poświęcam całą swoją moc mózgową (niewiele jest) na poprawne kodowanie, ból jest koniecznością cofania się i niszczenia wszystkiego przy limicie 80 znaków, kiedy mógłbym spędzać czas na następnej funkcji . Tak, przypuszczam, że Resharper mógłby to zrobić za mnie, ale wtedy trochę mnie przeraża, że ​​produkt innej firmy podejmuje decyzje dotyczące układu mojego kodu i zmienia go („Proszę nie rozbijać mojego kodu na dwie linie HAL. HAL?” ).

To powiedziawszy, pracuję w dość małym zespole, a wszystkie nasze monitory są dość duże, więc martwienie się o to, co przeszkadza moim innym programistom, nie jest wielkim zmartwieniem, jeśli chodzi o to.

Wygląda na to, że niektóre języki zachęcają do dłuższych wierszy kodu ze względu na większe korzyści (krótkie instrukcje if to).

domusvita
źródło
7

Mam dwa monitory 20 "1600x1200 i trzymam się 80 kolumn, ponieważ pozwala mi to wyświetlać wiele okien edytora tekstu obok siebie. Używając czcionki„ 6x13 "(czcionka trad. Xterm) 80 kolumn zajmuje 480 pikseli plus pasek przewijania i obramowania okien. Pozwala to na posiadanie trzech okien tego typu na monitorze 1600x1200. W systemie Windows czcionka Lucida Console tego nie robi (minimalny rozmiar użytkowy to 7 pikseli szerokości), ale monitor 1280x1024 wyświetli dwie kolumny i monitor 1920x1200, taki jak HP LP2465 , wyświetli 3. Pozostawi trochę miejsca z boku dla różnych eksploratorów, właściwości i innych okien programu Visual Studio.

Dodatkowo bardzo długie wiersze tekstu są trudne do odczytania. Dla tekstu optimum to 66 znaków. W pewnym momencie nadmiernie długie identyfikatory zaczynają przynosić efekty odwrotne do zamierzonych, ponieważ utrudniają spójne układanie kodu. Dobry układ i wcięcia dostarczają wizualnych wskazówek co do struktury kodu, a niektóre języki (przychodzi na myśl Python) używają do tego wcięć.

Jednak standardowe biblioteki klas dla Java i .Net mają przeważnie bardzo długie identyfikatory, więc nie można zagwarantować, że będzie to możliwe. W takim przypadku ułożenie kodu z podziałem wiersza nadal pomaga uczynić strukturę jawną.

Zauważ, że możesz pobrać wersje czcionek „6x13” dla systemu Windows tutaj .

ConcernedOfTunbridgeWells
źródło
Dziękuję za to! Duże monitory są tym bardziej powodem ograniczenia do 80 linii, dzięki czemu można zmieścić więcej okien obok siebie. Nie wspominając o tym, że fajnie jest móc czasami wydrukować kod źródłowy (na papierze). Lub wklej fragmenty do innych dokumentów.
dreeves
7

Ludzie mówią, że długie linijki kodu są zwykle skomplikowane. Rozważmy prostą klasę Java:

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

Ma 94 znaki, a nazwa klasy jest dość krótka (jak na standardy GWT). Byłoby trudne do odczytania w dwóch wierszach i jest bardzo czytelne w jednym wierszu. Będąc pragmatycznym i umożliwiając w ten sposób „kompatybilność wsteczną”, powiedziałbym, że 100 znaków to właściwa szerokość.

Matyas
źródło
5
Nie jestem fanem poziomych pasków przewijania
bryc
9
Jestem zaskoczony, że nikt tego nie powiedział, biorąc pod uwagę, że spóźniłem się kilka lat na tę dyskusję, ale myślę, że nowe wiersze (może z wcięciem dla przejrzystości) tuż przed słowami kluczowymi „rozszerza” i / lub „implementuje” nadal dawałyby bardzo czytelny kod.
mtraceur
2
Podoba mi się to, że jest napisane „jest bardzo czytelne w jednym wierszu”, a jednocześnie nie mogę odczytać całego fragmentu kodu, ponieważ przepełnia on poziomą przestrzeń w przeglądarce. Punkt obalony.
oligofren
6

Inne odpowiedzi już ładnie podsumowały, ale warto się zastanowić, kiedy możesz skopiować i wkleić jakiś kod do wiadomości e-mail, a jeśli nie kod, to różnicę.

To czas, w którym przydaje się „maksymalna szerokość”.

user14038
źródło
6

Nie jesteś jedyną osobą, która będzie utrzymywać Twój kod.

Następna osoba, która to zrobi, może mieć 17-calowy ekran lub może potrzebować dużej czcionki do odczytania tekstu. Limit musi być gdzieś, a 80 znaków to konwencja wynikająca z poprzednich ograniczeń ekranu. Czy przychodzi Ci do głowy jakiś nowy standard (120) i dlaczego dobrym pomysłem jest użycie innego niż "to, co pasuje do mojego monitora przy czcionce Xpt?"

Pamiętaj, że zawsze są wyjątki od każdej reguły, więc jeśli masz konkretną linię lub blok kodu, który ma więcej niż 80 znaków, wtedy być buntownikiem.

Ale najpierw pomyśl "czy ten kod jest naprawdę taki zły, że nie może zawierać 80 znaków?"

pappes
źródło
1
Będę żył z 80 znakami, kiedy będę mógł mieć 2 spc. Jeszcze lepiej, faktycznie używaj tabulatorów do wcięć, wymaganie jest takie, gdy rozmiar tabulacji = 2, mieści się w 80 kolumnach, używaj 4 przez większość czasu, aby uzyskać lepszą czytelność. W ten sposób, jeśli naprawdę musisz dławić się do 80 kolumn, możesz, ale za cenę.
Joshua
5

W standardzie kodowania Linuksa nie tylko zachowują limit 80 znaków, ale także używają wcięć 8 spacji.

Po części rozumowanie jest takie, że jeśli kiedykolwiek osiągniesz właściwy margines, powinieneś rozważyć przeniesienie poziomu wcięcia do oddzielnej funkcji.

Dzięki temu kod będzie bardziej przejrzysty, ponieważ niezależnie od długości wcięć trudniej jest odczytać kod z wieloma zagnieżdżonymi strukturami sterującymi.

Ali
źródło
3
A co z czytaniem kodu z wieloma wywołaniami funkcji? Z pewnością istnieje kompromis między tymi dwoma podejściami ...
Zsolt Török
5

Rozszerzyłem mój kod do 100 znaków, co wygodnie mieści się na mniej niż połowie ekranu mojego Macbooka. 120 znaków to prawdopodobnie limit, zanim wiersze staną się zbyt długie i skomplikowane. Nie chcesz wchodzić zbyt szeroko, bo inaczej zachęcasz do instrukcji złożonych i głęboko zagnieżdżonych struktur kontrolnych.

Właściwy margines to naturalny sposób, który każe Ci wykonać dodatkową refaktoryzację metody .

Schwern
źródło
5

Zastanawiam się, czy może to spowodować więcej problemów w dzisiejszych czasach. Pamiętaj, że w C (i być może w innych językach) istnieją zasady określające, jak długo może być nazwa funkcji. Dlatego w kodzie C często spotyka się bardzo trudne do zrozumienia nazwy. Dobrą rzeczą jest to, że nie zajmują dużo miejsca. Ale za każdym razem, gdy patrzę na kod w jakimś języku, takim jak C # lub Java, nazwy metod są często bardzo długie, co sprawia, że ​​przechowywanie kodu o długości 80 znaków jest prawie niemożliwe. Nie wydaje mi się, aby dziś 80 znaków było ważnych, chyba że musisz być w stanie wydrukować kod itp.

Jonas
źródło
5

Jako autor wskazówek dotyczących kodowania dla mojego pracodawcy podniosłem długość linii z 80 do 132. Skąd ta wartość? Cóż, jak wskazywali inni, 80 to długość wielu starych terminali sprzętowych. I 132 również! Jest to szerokość linii, gdy terminale są w trybie szerokim . Każda drukarka mogłaby również tworzyć wydruki w trybie szerokim ze skondensowaną czcionką.

Powodem, dla którego nie mam 80 lat, jest to, że ja raczej

  • wolą dłuższe nazwy ze znaczeniem dla identyfikatorów
  • nie zawracaj sobie głowy typedefami dla struktur i wyliczeń w C (są ZŁE, UKRYJĄ przydatne informacje! Zapytaj Petera van der Lindena w "Deep C Secrets", jeśli w to nie wierzysz), więc kod ma więcej struct FOO func(struct BAR *aWhatever, ...)niż tylko kod fanatyków typedef .

a zgodnie z tymi zasadami tylko 80 znaków / linię powoduje brzydkie zawijanie linii częściej niż moje oczy uznają za dopuszczalne (głównie w prototypach i definicjach funkcji).

Jens
źródło
4

Jak powiedzieli inni, myślę, że jest najlepszy do (1) drukowania i (2) wyświetlania wielu plików obok siebie w pionie.

Thomas Owens
źródło
4

Lubię ograniczać swoją szerokość do około 100 znaków, aby umożliwić korzystanie z dwóch edytorów SxS na panoramicznym monitorze. Nie wydaje mi się, aby istniał już jakiś dobry powód, aby wprowadzić limit dokładnie 80 znaków.

Jamie Eisenhart
źródło
4

Używaj czcionek proporcjonalnych.

Jestem poważny. Zwykle mogę uzyskać równoważność 100-120 znaków w wierszu bez poświęcania czytelności lub drukowności. W rzeczywistości jest jeszcze łatwiejszy do odczytania dzięki dobrej czcionce (np. Verdana) i kolorowaniu składni. Przez kilka dni wygląda to trochę dziwnie, ale szybko się do tego przyzwyczajasz.

bgiles
źródło
Naprawdę zły pomysł, gdy chcesz użyć „wcięć” i czcionek o stałej szerokości.
Bersaelor
2
@Bersaelor Nie, działa dobrze, gdy zawsze używasz wcięć za pomocą samych tabulatorów i odpowiednio ustawiasz szerokość tabulatora (szerokość 4 o stałej szerokości to być może 7 proporcjonalnych). Wcięcia działają, po prostu nie możesz robić grafiki ASCII, ale nie sądzę, że grafika ASCII należy do kodu.
maaartinus
Osobiście, programując, jestem po zupełnie przeciwnej stronie. Uważam, że kod proporcjonalny jest naprawdę trudny do odczytania. Czasami nawet konfiguruję IDE, aby używać czcionek o stałej szerokości (tak, w tym menu).
Sebastian Mach
2

Staram się ograniczyć liczbę znaków do 80 znaków z prostego powodu: zbyt dużo więcej oznacza, że ​​mój kod staje się zbyt skomplikowany. Zbyt szczegółowe nazwy właściwości / metod, nazwy klas itp. Powodują tyle samo szkód, co lakoniczne.

Jestem przede wszystkim programistą Pythona, więc daje to dwa zestawy ograniczeń:

  1. Nie pisz długich linii kodu
  2. Nie wciskaj zbyt dużo

Kiedy zaczynasz osiągać dwa lub trzy poziomy wcięć, twoja logika staje się zagmatwana. Jeśli nie możesz zachować pojedynczego bloku na tej samej stronie, kod staje się zbyt skomplikowany i trudny do zapamiętania. Jeśli nie możesz zachować pojedynczej linii zawierającej 80 znaków, twoja linia staje się zbyt skomplikowana.

W Pythonie łatwo jest napisać stosunkowo zwięzły kod (patrz codegolf) kosztem czytelności, ale jeszcze łatwiej jest pisać pełny kod kosztem czytelności. Metody pomocnicze nie są złe, podobnie jak klasy pomocnicze. Nadmierna abstrakcja może być problemem, ale to kolejne wyzwanie związane z programowaniem.

Jeśli masz wątpliwości w języku takim jak C, napisz funkcje pomocnicze i wstaw je, jeśli nie chcesz, aby narzut związany z wywołaniem innej funkcji i skokiem wstecz. W większości przypadków kompilator w inteligentny sposób poradzi sobie z tym za Ciebie.

Dan Udey
źródło
2

Jest już na to wiele dobrych odpowiedzi, ale warto wspomnieć, że w swoim IDE możesz mieć listę plików po lewej stronie, a listę funkcji po prawej (lub inną konfigurację).

Twój kod to tylko jedna część środowiska.

Dean Rather
źródło
2

Nie wymuszanie 80 znaków oznacza ostatecznie zawijanie słów.
IMO, dowolna długość wybrana dla linii o maksymalnej szerokości nie zawsze jest odpowiednia, a możliwą odpowiedzią powinno być zawijanie słów.
A to nie jest takie proste, jak się wydaje.

Jest zaimplementowany w jedit (źródło: jedit.org ), który umożliwia zawijanie słówtekst alternatywny

Ale gorzko tęskni za zaćmieniem od dawna ! (właściwie od 2003 roku), głównie dlatego, że zawijanie słów w edytorze tekstu obejmuje:

  • Informacje o zawiniętych liniach są przeznaczone dla przeglądarki tekstu, nawigacji po kodzie, linijek pionowych.
  • Informacje o nierozwiniętych wierszach są wymagane w przypadku funkcji takich jak linia goto, kolumna linijki numeracji linii, podświetlenie bieżącego wiersza, zapisywanie pliku.
VonC
źródło
1

W rzeczywistości stosuję podobną zasadę dla własnego kodu, ale tylko ze względu na drukowanie kodu na stronie A4 - 80 kolumn to mniej więcej szerokość odpowiednia dla mojego pożądanego rozmiaru czcionki.

Ale to osobiste preferencje i prawdopodobnie nie to, o co ci chodziło (ponieważ chcesz, aby amunicja poszła w drugą stronę).

Czego nie kwestionujesz uzasadnienia tego limitu - poważnie, jeśli nikt nie może wymyślić dobrego powodu, dla którego tak jest, masz dobry argument za usunięciem go ze standardów kodowania.

paxdiablo
źródło
Jestem prawie pewien, że pochodzi z czasów, gdy ekrany trybu tekstowego miały szerokość 80 znaków.
TraumaPony,
1

Różnicuję się obok siebie przez cały dzień i nie mam cholernego 22-calowego monitora. Nie wiem, czy kiedykolwiek to zrobię. To oczywiście nie jest interesujące dla programistów zajmujących się tylko pisaniem, korzystających z kodowania strzałkami i 300-znakowych linii.

Constantin
źródło
1

Tak, ponieważ nawet w dzisiejszych czasach niektórzy z nas kodują na terminalach (ok, głównie emulatorach terminali), na których wyświetlacz może wyświetlać tylko 80 znaków. Tak więc, przynajmniej jeśli chodzi o kodowanie, naprawdę doceniam zasadę 80 znaków.

CobolGuy
źródło
0

Nadal uważam, że granica nie jest ograniczona od strony wizualnej. Jasne, monitory i rozdzielczości są obecnie wystarczająco duże, aby pokazać jeszcze więcej znaków w jednej linii, ale czy zwiększa to czytelność?

Jeśli limit jest naprawdę wymuszony, jest to również dobry powód, aby ponownie przemyśleć kod i nie umieszczać wszystkiego w jednej linii. Tak samo jest z wcięciami - jeśli potrzebujesz dużo poziomów, musisz ponownie przemyśleć kod.

nieistniejący
źródło
0

Łamanie 80 znaków to coś, co robisz podczas kodowania, a nie później. Oczywiście to samo z komentarzami. Większość redaktorów może pomóc w sprawdzeniu, gdzie jest limit 80 znaków.

(To może być trochę OT, ale w Eclipse jest opcja formatowania kodu podczas jego zapisywania (zgodnie z dowolnymi regułami). Na początku jest to trochę dziwne, ale po chwili zaczynasz akceptować, że formatowanie nie leży w twoich rękach bardziej niż wygenerowany kod).

JesperE
źródło
0

Gdybyśmy mieli jeden z nich , nie prowadzilibyśmy tej dyskusji! ;-)

Ale poważnie, kwestie, które ludzie poruszyli w swoich odpowiedziach, są całkiem uzasadnione. Jednak oryginalny plakat nie spierał się z ograniczeniem, a jedynie, że 80 kolumn to za mało.

Kwestia wysyłania fragmentów kodu e-mailem ma pewne zalety. Ale biorąc pod uwagę złe rzeczy, które większość klientów pocztowych robi z wstępnie sformatowanym tekstem, myślę, że zawijanie wierszy to tylko jeden z twoich problemów.

Jeśli chodzi o drukowanie, zwykle stwierdzam, że 100 linii znaków bardzo wygodnie zmieści się na wydrukowanej stronie.

Andrew Edgecombe
źródło
0

Staram się utrzymywać linie poniżej 80 kolumn. Najsilniejszym powodem jest to, że często używam grepi lessprzeglądam kod podczas pracy w wierszu poleceń. Naprawdę nie podoba mi się, jak terminale łamią długie linie źródłowe (w końcu nie są do tego stworzone). Innym powodem jest to, że wydaje mi się, że wygląda lepiej, jeśli wszystko pasuje do wiersza i nie jest zepsute przez edytor. Na przykład posiadanie parametrów długich wywołań funkcji ładnie wyrównanych względem siebie i podobnych rzeczy.

Johannes Schaub - litb
źródło