Ну, чи так? Чи вважається це поганою практикою?

ІМО, він менш читабельний. Я ненавиджу прокручувати вправо, потім вліво, вправо, вліво тощо. Це робить кодування більш болючим і іноді мене бентежить.

Наприклад, у будь-який час, коли я кодую довгу рядок, я зроблю наступне ...

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

Так, це дійсно так, як в прямому, так і в загальному сенсі.

Мені подобається робити кодовий розбіг, і занадто широкі рядки роблять це складніше:

Такі мови, як Scala, з рядками з потрійним цитуванням, дозволяють побудувати рядок з багатьох рядків без витрат на час виконання, непривабливі лапки та знаки плюс (як видно з вашого прикладу) об'єднання частин рядка.

Так, я вважаю, що 80 символів на рядок є розумним і поширеним.

Це дійсно важливе питання для мене! Я працював 7 місяців на 13-дюймовому ноутбуці з колегами, що мають 24-дюймові настільні монітори, і я виявив, що витрачаю багато часу на скорочення ліній, щоб закінчитися чимось читабельним.

80 стовпців у багатьох випадках трохи (за винятком випадків, коли ви працюєте на терміналі з vi єдиною опцією;)), але більше ~ 150 - це занадто багато (див. Нижче).

Це для чистого питання "читабельності".

Тепер, для частини "належної практики", я дуже часто виявляю недоліки таких довгих рядків, тобто маю частину, яку слід витягти у тимчасовій змінній або дублювати, наприклад (ObjectiveC, загальний фрагмент в програмуванні iPhone) :

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

Зверніть увагу, що це може стати ще більш неприємним при роботі з 3-мірними векторами або матрицями.

Переписаний приклад:

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

Тепер це вміщується на меншому екрані, простіше налагоджувати за допомогою IDE або деякого запису до стандартного виводу, а може навіть швидше, залежно від вартості виклику методу / властивості. Це трохи вимушено, звичайно, більшість прикладів реального світу набагато складніші ...

Не завжди.

Просто для додання альтернативної точки зору, коли я читаю код, я часто можу отримати суть того, що робить рядок коду, без того, щоб читати весь рядок. Якщо я можу прочитати ім'я методу, але параметри методу випливають із екрана, я зазвичай не метушнюсь, тому що я можу сказати лише від імені методу, яка мета цього рядка коду. Якщо кілька рядків коду випливають з екрану, то я думаю, що компроміс з необхідності періодично (важливе слово там) прокручувати горизонтально варто того, щоб отримати більш компактний код. Іноді я вважаю, що багаторядковий код одного твердження відволікає увагу, оскільки мені доводиться подумки поєднувати, який код іде з тим твердженням.

Часто рядки коду, які перекидаються горизонтально, мають свої важливі біти зліва (видимі) та менш важливі біти праворуч (поза екраном), тому для мене це підвищує читабельність, оскільки я можу сканувати код вниз, в основному бачачи важливі біти у кожному рядку, на відміну від альтернативи наявності менш важливих бітів коду із занадто довгої рядка, що займає візуально важливий простір лівої сторони у наступних рядках.

Сказавши все це, я, звичайно, не хотів би прокручувати горизонтально дуже часто, але я знаходжу це менше проблеми в ці дні широкоекранного монітора.

Так.

До речі, підказка. Якщо ви використовуєте мову з багаторядковими рядками (практично у всіх мовах скриптів є їх) і включають довгий SQL, це дійсно допомагає читати, щоб розмістити SQL у рядковому рядку з використанням послідовних правил форматування для SQL. Дивіться http://bentilly.blogspot.com/2011/02/sql-formatting-style.html про стиль форматування, який я використовую.

Ні, це не так.

У мене є редактор. Має не лише обертання рядків, але й відступ обертання рядка , що (якщо екран скаже шириною 100 символів) спричинить

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.

здаватися як

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.

або з будь-яким рівнем відступу встановлено за умовчанням для поточної мови.

Рядки ширше мого екрана ніколи не роблять код менш читабельним порівняно з кодом, відведеним вручну з відступом рядків.

редагувати: ooooh, я знав, що ця відповідь буде непопулярною :)

Звичайно, так і є. Є причина, що газети та журнали використовують колонки. Читання - важливий фактор. При читанні наші очі сканують вниз з відносно невеликим рухом в бік. Ефект полягає в тому, щоб дозволити нашим очам швидко сканувати те, що ми читаємо.

Навіть коли вони видно на широких стовпцях екрану, змушують наші очі швидко сканувати назад і назад. Під час сканування назад ми насправді нічого не розуміємо. Це значно сповільнить читання та розуміння. Ефект схожий на старі механічні принтери. Вони часто вимагають вставити кілька нульових символів після повернення каретки, щоб забезпечити час для перевезення вантажівки або друкованої головки для наступного рядка.

Додатково вертикальний макет зазвичай робиться таким чином, щоб уточнити групування вмісту в рядку. Зазвичай це стосується лише складних логічних умов. Довгі формули можуть бути краще структуровані у вигляді серії тверджень. (Оптимізатор виправить будь-які додаткові накладні витрати, а деякі оптимізатори відмовляться або погано працюватимуть у складних формулах.)

Ідентифікатори з декількома крапками, які потребують великих рядків, вказують методи кодування, які слід виправити.

Миші-колеса дозволяють легко прокручувати вертикально швидко ... прокрутка по горизонталі занадто дорога в порівнянні.

Уникайте горизонтального прокручування.

~ Рекомендації щодо взаємодії з користувачем Windows, сторінка 112

Так.

Англійці читають зліва направо, що призводить до постійної прокрутки = Непродуктивно

З цієї причини я завжди дозволяю обгортати слова з візуальними гліфами ліній у моєму IDE.