(Przepraszam, jeśłi dział jest zły - chyba nie pasuje do tego pytania, ale wszystkie inne pasują jeszcze gorzej... jeśli jednak ten temat winien znaleźć się gdzie indziej, to proszę o przeniesienie)
Dawno, dawno temu, w czasach, o które tylko największych starców w królestwie pytać można, był nacisk, by jedna linijka kodu miała nie więcej, jak 80 znaków. Tyle bowiem wynosiła szerokość terminala i tyle się mieściło wszerz na kartce A4.
Ale minęły całe epoki, stare dzieje rozmyły się już w mrokach niepamięci, nic już nie zostało po chwale Starożytnych, nic oprócz kilku porozrzucanych po świecie reliktów i podań, zniekształconych przez ciągłe powtarzanie. Teraz kod jest rzadko drukowany, jeśli w ogóle. Na monitorze mieści się dużo więcej, niż 120 znaków, o 80 już nie wspominając.
A jednak preferencja dotycząca krótkich linii pozostaje. Standardy stylu zazwyczaj wymagają 80, 100 albo 120 znaków, lub też każą wybrać sobie jeden z tych limitów i się go trzymać. Raczej chyba(?) nie spotyka się dłuższych. I to niezależnie od języka. Dlaczego?
Wydaje mi się, że długie linie (tak, by zmieściły się na najwęższym monitorze spośród wykorzystywanych przez zespół) miałyby sens, ponieważ:
- Jest presja na długie, opisowe nazwy klas, metod, zmiennych. Gdyby wolno było stosować skrótowce, to inna sprawa, ale nie wolno. Wobec tego w jednej krótkiej linii spokojnie może się nie zmieścić deklaracja albo wywołanie funkcji wraz z jej argumentami.
- Obecnie zaleca się niestosowanie konstrukcji imperatywnych (np.
for) tam, gdzie łatwo można je zastąpić konstrukcjami funkcyjnymi (LINQ i takie tam). Ale to wszystko to jest jeden expression tam, gdzie dawniej było kilka statements.
Wobec tego krótkie linie wymagają częstego dzielenia jednej linii na wiele. Byc może to kwestia (złego) doświadczenia, ale przyzwyczaiłem się do jednego statement na linię. Dzielenie statement na wiele linii mnie konfuduje.
I o ile mogę jeszcze zrozumieć rozbijanie linii na kropce, np.
var foo = bar
.Where(b => Cond(b))
.Select(b => b.baz)
.Max();
o tyle rozbijanie nawiasów okrągłych mnie osobiście wydaje się już być skrajnie brzydkie. I znowu: w wielu punktach, gdy zachodzi potrzeba rozbicia nawiasu okrągłego można dać argument, że winna jest niedostateczna granulacja kodu: np. jeśli nie mieści się w jednej linii warunek w ifie, to ten warunek winien stać się osobną metodą, i jeśli lambda w Select się nie mieści, to znów zamiast lambdy trzeba tam przekazać osobną metodę, itp. Ale co, jeśli - jak pisałem wyżej - nie mieści się nazwa metody wraz z jej argumentami?
Jeszcze jeden argument, choć najsłabszy ze wszystkich:
- To jest marnowanie dostępnej przestrzeni. Po co szeroki monitor, skoro się go nie wykorzystuje inaczej, jak na białe lub szare tło?
Często spotykanym argumentem jest, że krótkie linie czyta się łatwiej. Zastanawiam się jednak, na ile to jest fakt, a na ile jest to dogmat nieznajdujący oparcia w rzeczywistości, który nabrał wagi przez to, że jest ciągle powtarzany. Mnie osobiście długie linie nie przeszkadzały, czy to w kodzie, czy to w prozie. Irytowało mnie nawet, że tyle stron internetowych mocno skraca linie. Choć nie wszystkie; Wikipedia tego, co ciekawe, nie robi.
Ciekawe, że w artykule na temat długości linii w prozie Wikipedia pisze:
Subjective factors also play a role in line length selection for digital text. One study has found that CPL had only small effects on readability, including factors of speed and comprehension; but when asked for preferences, 60% of respondents indicated a preference for either the shortest (35 CPL) or longest (95 CPL) lines used in the study. At the same time, 100% of respondents selected either one of these quantities as being the least desirable.
Być może zatem mamy tu do czynienia ze sprawą subiektywną, którą się traktuje tak, jakby była obiektywna?