Cóż, prawda? Czy jest to uważane za złą praktykę?

IMO jest mniej czytelny. Nienawidzę konieczności przewijania w prawo, a następnie w lewo, w prawo, w lewo i tak dalej. To sprawia, że ​​kodowanie jest bardziej bolesne i czasami mnie myli.

Na przykład za każdym razem, gdy koduję długi ciąg, wykonam następujące czynności ...

bigLongSqlStatement = "select * from sometable st inner join anothertable at" +
"on st.id = at.id" +
"and so on..." +
"and so on..." +
"and so on..."

Tak, rzeczywiście tak jest, zarówno w sensie dosłownym, jak i ogólnym.

Lubię robić równoległe różnice w kodzie, a zbyt szerokie linie utrudniają to:

Języki, takie jak Scala z potrójnymi cytatami, pozwalają na konstruowanie łańcucha z wielu wierszy bez kosztów wykonania, nieestetycznych cytatów i znaków plus (jak widać na twoim przykładzie) łączenia ze sobą części łańcucha.

Tak, myślę, że 80 znaków w wierszu jest rozsądne i powszechnie używane.

To dla mnie bardzo ważne pytanie! Pracowałem 7 miesięcy na 13-calowym laptopie z kolegami mającymi 24-calowe monitory stacjonarne i odkryłem, że spędzam dużo czasu na skracaniu linii, aby uzyskać coś czytelnego.

80 kolumn jest nieco małych w wielu przypadkach (z wyjątkiem jeśli pracujesz na terminalu z vi jedyną opcją;)), ale więcej niż ~ 150 to za dużo (patrz poniżej).

To dotyczy czystego pytania „czytelności”.

Teraz, w części „dobrych praktyk”, bardzo często zdarza mi się, że tak długie linie są wadliwe, tj. Mają część, która powinna zostać wyodrębniona w zmiennej tymczasowej lub która jest na przykład zduplikowana (ObjectiveC, wspólny fragment w programowaniu iPhone'a) :

CGPoint point = CGPointMake(someOtherView.frame.origin.x + someOtherView.frame.size.width, someOtherView.frame.origin.x + someOtherView.frame.size.height);

Pamiętaj, że może to stać się jeszcze bardziej nieprzyjemne podczas pracy z trójwymiarowymi wektorami lub macierzami.

Przepisany przykład:

CGRect frame = someOtherView.frame;
CGPoint origin = frame.origin;
CGSize size = frame.size;
CGPoint point = CGPointMake(origin.x + size.width, origin.x + size.height);

Jest to teraz dopasowane na mniejszym ekranie, łatwiejsze do debugowania za pomocą IDE lub zapisu na standardowe wyjście, a może nawet być szybsze, w zależności od kosztu wywołania metody / właściwości. Jest to oczywiście trochę wymuszone, większość przykładów ze świata rzeczywistego jest znacznie bardziej złożona ...

Nie zawsze.

Aby dodać alternatywny widok, kiedy czytam kod, często mogę uzyskać sedno tego, co robi linia kodu, bez konieczności czytania całego wiersza. Jeśli potrafię odczytać nazwę metody, ale parametry metody wylewają się z ekranu, zwykle nie jestem zdenerwowany, ponieważ z samej nazwy metody mogę dowiedzieć się, jaki jest cel tego wiersza kodu. Jeśli kilka linii kodu wyleje się z ekranu, myślę, że kompromis związany z koniecznością (ważnego słowa) przewijania w poziomie jest tego warty dla bardziej zwartego kodu. Czasami zdarza mi się, że wieloliniowy kod z pojedynczą instrukcją rozprasza, ponieważ muszę mentalnie poskładać, który kod pasuje do której instrukcji.

Często linie kodu, które się rozlewają w poziomie, mają swoje ważne bity po lewej stronie (widoczne) i mniej ważne bity po prawej stronie (poza ekranem), więc dla mnie poprawia to czytelność, ponieważ mogę skanować kod w dół, głównie widząc ważne bity w każdej linii, w przeciwieństwie do alternatywy polegającej na tym, że mniej ważne bity kodu z zbyt długiej linii zajmują ważne wizualnie miejsce po lewej stronie w kolejnej linii.

Powiedziawszy to wszystko, z pewnością nie chciałbym bardzo często przewijać w poziomie, ale w czasach monitorów z szerokim ekranem nie mam większego problemu.

Tak.

Nawiasem mówiąc, wskazówka. Jeśli używasz języka z ciągami wieloliniowymi (praktycznie mają je wszystkie języki skryptowe) i dołączasz długi SQL, to naprawdę pomaga czytelność umieścić SQL w ciągu wieloliniowym przy użyciu spójnych reguł formatowania dla SQL. Zobacz http://bentilly.blogspot.com/2011/02/sql-formatting-style.html styl, którego używam.

Nie, nie ma.

Mam redaktora. Ma nie tylko zawijanie linii, ale także wcięcie linii , które (jeśli na ekranie jest powiedzmy 100 znaków)

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

wyglądać jak

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut 
    labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco 
    laboris nisi ut aliquip ex ea commodo consequat.

lub z dowolnym poziomem wcięcia ustawionym jako domyślny dla bieżącego języka.

Linie szersze niż mój ekran nigdy nie czynią kodu mniej czytelnym w porównaniu do kodu z wcięciem ręcznie.

edytuj: ooooh, wiedziałem, że ta odpowiedź będzie niepopularna :)

Z pewnością tak jest. Jest powód, dla którego gazety i czasopisma używają kolumn. Czytelność jest istotnym czynnikiem. Podczas czytania nasze oczy skanuj w dół przy stosunkowo niewielkim ruchu na boki. Dzięki temu nasze oczy mogą szybko skanować to, co czytamy.

Nawet gdy widoczne na ekranie szerokie kolumny zmuszają nasze oczy do szybkiego skanowania w tę iz powrotem. Podczas skanowania wstecz tak naprawdę nic nie rozumiemy. Znacząco spowolni to czytanie i rozumienie. Efekt jest podobny do starych drukarek mechanicznych. Często wymagały one wstawienia kilku znaków zerowych po powrocie karetki, aby dać czas na zmianę położenia karetki lub głowicy drukującej w następnym wierszu.

Ponadto układ pionowy jest zwykle wykonywany w taki sposób, aby wyjaśnić grupowanie zawartości w wierszu. Zwykle powinno to dotyczyć tylko złożonych warunków logicznych. Długie formuły mogą być lepiej skonstruowane jako seria instrukcji. (Optymalizator naprawi wszelkie dodatkowe koszty, a niektóre optymalizatory zrezygnują lub będą słabo działać na złożonych formułach).

Identyfikatory z wieloma kropkami wymagające dużych linii wskazują techniki kodowania, które należy poprawić.

Mysz-koła ułatwiają szybkie przewijanie w pionie ... przewijanie w poziomie jest zbyt drogie w porównaniu.

Unikaj przewijania w poziomie.

~ Wytyczne dotyczące interakcji użytkownika z systemem Windows Str. 112

Tak.

Anglicy czytają od lewej do prawej, co powoduje ciągłe przewijanie = nieproduktywne

Z tego powodu zawsze włączam zawijanie słów za pomocą wizualnych glifów linii w moim IDE.