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

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.

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 .

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:

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

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.

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

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

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.

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.

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

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 .

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

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

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

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.

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 .

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.

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

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

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.

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.

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.

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.

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łów

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.

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.

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.

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.

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.

Ł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).

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.

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.