Есть ли веская причина для обеспечения максимальной ширины 80 символов в файле кода, в этот день и возраст? [закрыто]

159

Шутки в сторону. На 22-дюймовом мониторе он покрывает только четверть экрана. Мне нужны боеприпасы, чтобы уменьшить это правило.


Я не говорю, что не должно быть предела; Я просто говорю, 80 символов очень мало.

TraumaPony
источник
Все ответы в значительной степени указывают на то, что я хотел добавить. Чтобы привести пример из жизни - у меня есть x61s, разрешение 1024x768. Когда я в дороге, у меня нет своего модного монитора. Открытие кода в моей IDE - боль, когда оно превышает это правило.
до
возможный дубликат stackoverflow.com/questions/95575/…
Даже если у вас есть набор из 3 мониторов. Это не повод качать головой справа налево и обратно. Навсегда. Ах-ха-ха. На самом деле глаз движется быстрее, чем голова. Вы знаете о колонках в газеты? Причиной ширины является удобство глаз / голова / человек.
Иван Блэк

Ответы:

258

Я думаю, что практика сохранения кода в 80 (или 79) столбцах изначально была создана для поддержки людей, редактирующих код на немых терминалах с 80 столбцами или на распечатках с 80 столбцами. Эти требования в основном исчезли, но есть все еще веские причины для сохранения правила 80 столбцов:

  • Чтобы избежать переноса при копировании кода в электронную почту, веб-страницы и книги.
  • Для просмотра нескольких окон источника рядом или с помощью средства просмотра различий рядом.
  • Для улучшения читабельности. Узкий код можно прочитать быстро, не сканируя глаза из стороны в сторону.

Я думаю, что последний пункт является наиболее важным. Хотя за последние несколько лет дисплеи выросли в размерах и разрешении, глаза - нет .

Will Harris
источник
7
Возможно, они «в значительной степени ушли», но не полностью. Я склонен работать с двумя разными настройками: 1) в окне ssh, подключенном к удаленной машине. которая составляет 80 символов в ширину по умолчанию. и 2) В Visual Studio, с двумя панелями рядом, чтобы я мог видеть заголовок и файл cpp одновременно.
Энно
10
@steffenj: На самом деле, книги , как правило, стрелять в течение примерно 66 символов в строке (хотя это несколько меняется в зависимости от других параметров) , так как длинные линии делают делают чтение более трудным. Можно утверждать о максимальной длине строки кода , но 80 удобно по историческим и практическим причинам.
Стив С
70
Проблема заключается в том, что люди вынуждены сокращать длину строк, они обычно используют менее значимые имена ...
Ян Рингроз
4
Я нахожу замечания по поводу читабельности довольно интересными, потому что в печатных статьях / книгах по программированию / ... я ненавижу то, что короткие строки, которые используются для примеров кода, чрезвычайно трудно читать. Может иметь смысл переместить что-то на новую строку, но группировка должна происходить логически, рекурсивно разбирая выражение, а не потому, что устройство вывода случайно достигло своего ограничения. Я нахожу, что устройства, налагающие такие узкие ограничения, плохо подходят для отображения кода.
Крис Лерчер,
4
Я думаю, что проблема с 80-столбцов-исполнителей заключается в том, что они забывают, что код вместо этого растет в вертикальном направлении. Вы получаете ту же проблему, но в вертикальном направлении И вершины этого современного кода выглядит ужасно, когда вам нужно разбить отдельные операторы на две, а иногда до четырех или пяти строк. Это НЕ более читабельно. В современном коде я имею в виду описательные имена переменных и квалифицирующее наследование, пространства имен, классы и т. Д. Пожалуйста, остановите бессмысленный 80-колоночный случай, используйте вместо этого здравый смысл. 120 лучше, но не должно быть правилом.
Ларсвад
79

Источником форматирования текста из 80 столбцов является более ранняя версия, чем терминалы из 80 столбцов - перфокарта IBM датируется 1928 годом ! Это напоминает (апокрифическую) историю о том, что железнодорожная колея в США определялась шириной колесниц колесниц в римской Британии.

Я иногда нахожу это немного сужающим, но имеет смысл иметь некоторый стандартный предел, так что 80 столбцов это так.

Вот та же тема, которую освещает Slashdot .

А вот заявление Фортрана старой школы:

Фортран перфокарта

Джон Картер
источник
59

80 символов - это смешное ограничение в наши дни. Разделите строки кода там, где это имеет смысл, а не в соответствии с произвольным ограничением символов.

День крейга
источник
1
Ограничение на число символов не говорит вам, ГДЕ вы должны разделить строку кода, но КОГДА
gztomas
Нет это не так. Если вы пишете строку длиной более 80 символов, у вас, вероятно, уже есть проблема в сложности выражений или стратегии именования. Как уже упоминали другие, читаемость является главной проблемой, и скорость чтения начинает падать выше 60-66 символов (типография, основанная на физиологии человека).
Sola
@sola Ваш комментарий появляется здесь с 98 символами, и это - плотный естественный не родной язык (для меня), чтобы понять. Полностью разборчивый. Код с 3-4 отступами, синтаксическими маркерами и т. Д. Еще проще.
Вийпс
Я случайно отклонил этот ответ и больше не могу его голосовать. :(
Энди
35

Вы должны сделать это ради всех, у кого нет 22-дюймового широкоэкранного монитора. Лично я работаю на 17-дюймовом мониторе 4: 3, и я считаю, что он достаточно широк. Тем не менее, у меня также есть 3 из этих мониторов, поэтому у меня все еще есть много полезного пространства экрана.

Не только это, но человеческий глаз на самом деле имеет проблемы с чтением текста, если строки слишком длинные. Слишком легко заблудиться, на какой линии ты находишься. Газеты имеют ширину 17 дюймов (или что-то подобное), но вы не видите, как они пишут всюду по странице, то же самое касается журналов и других печатных материалов. На самом деле легче читать, если вы держите столбцы узкими.

Kibbee
источник
14
Не тогда, когда вы добавляете отступ в смесь. Если вы используете 4 пробела для отступа, и вы во что-то вроде, namespace-> class-> method-> if-> for, это 1/5 вашего пробела.
TraumaPony
Вы всегда можете установить правило в 80 символов из отступа. Таким образом, глаз может легко следовать за ним.
Винсент Макнабб
Иногда (но не всегда) хотелось бы, чтобы .Net имел автоматическое пространство имен, чтобы вам не приходилось определять пространство имен в файле. Это серьезно мешает выравниванию вашего кода. если вам нужны вложенные пространства имен, у вас действительно большие проблемы.
Кибби
13
Однако чтение прозы - это не то же самое, что чтение кода.
Atario
3
+1 для газет, отличный пример. @ Атарио, чтение ХОРОШЕГО кода очень похоже на чтение прозы.
Тодд Чаффи
23

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

Я бы сказал, что следующее намного более читабельно, чем если бы я разбил его на несколько строк:

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;
}

Обновление: в комментарии было предложено, чтобы это было более кратким способом сделать выше:

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; 

хотя теперь он умещается в 80 столбцов, я думаю, что моя точка зрения остается неизменной, и я просто выбрал плохой пример. Это все еще демонстрирует, что размещение нескольких операторов в строке может улучшить читаемость.

Сэм Хаслер
источник
8
Говоря, что между строками есть только небольшие различия, вы также говорите, что существует много избыточного кода. Удаление некоторых из них может значительно уменьшить количество столбцов и по-прежнему выравниваться по вертикали.
Foraidt
@mxp: согласен. Если есть более краткий способ написания вышеизложенного, мне было бы интересно его увидеть.
Сэм Хаслер
Я согласен с общей идеей, но пример ... Как насчет этого: switch (...) {case ... BL: dxDir = - 1; dyDir = - 1; перерыв; case ... BR: dxDir = + 1; dyDir = - 1; перерыв; ...} ... ["X"] = pt1.x + dxDir * Rad ... X; ... ["Y"] = pt1.y + dyDir * Rad ... Y;
Ярик
38
Тот факт, что мне нужно прокрутить первый из двух примеров по горизонтали, доказывает, что более короткие строки лучше :-)
Enno
1
Я не понимаю ненависть к прокрутке? Это общее мнение, и я не говорю, что это неправильно, я просто не понимаю этого. Особенно, если вы работаете в редакторе кода, вам даже не нужно отрывать руки от клавиатуры, чтобы добраться до мыши - просто(ctrl+)arrow выше или нажмитеend
KOGI
21

Печать моноширинного шрифта с размерами по умолчанию составляет (на бумаге формата А4) 80 столбцов на 66 строк.

мистифицировать
источник
16

Я использую преимущество больших экранов, чтобы иметь несколько кусков кода рядом друг с другом.

Вы не получите от меня боеприпасы. На самом деле, я не хотел бы видеть, как это изменилось, поскольку в чрезвычайных ситуациях я все еще вижу редкие случаи, когда мне нужно изменить код из текстовой консоли.

Twan
источник
14

Сверхдлинные строки труднее читать. Тот факт, что на вашем мониторе может отображаться 300 символов, не означает, что вы должны делать строки такими длинными. 300 символов также слишком сложны для утверждения, если у вас нет выбора (вызов, который требует целую кучу параметров.)

Я использую 80 символов в качестве общего правила, но я выйду за рамки этого, если его применение будет означать размещение разрыва строки в нежелательном месте.

Лорен Печтель
источник
Существуют исследования, которые показывают, что люди могут читать и следить за количеством символов / слов, прежде чем они потеряют след. Я думаю, что 80 где-то там. У меня нет никаких источников, чтобы поддержать это все же.
до
Да, на самом деле, я думаю, дело не в том, чтобы строки были короткими, а в том, чтобы поддерживать чистоту / краткость / читабельность / понятность.
КОГИ
Если у вас есть (вызов, который требует целую кучу параметров), вам все равно нужно провести некоторый рефакторинг.
Zarremgregarrok
@Zarremgregarrok Я видел несколько очень длинных списков параметров в API-интерфейсах Microsoft.
Лорен Печтел
@LorenPechtel Это делает это хорошо написанным?
Zarremgregarrok
8

Единственное, что я заставляю оставаться в пределах 80 символов, это мои комментарии.

Лично ... Я посвящаю все свои умственные способности (что мало есть) правильному кодированию, мне больно возвращаться и разбивать все на пределе 80 символов, когда я мог бы тратить свое время на следующую функцию , Да, Resharper мог бы сделать это для меня, я полагаю, но потом меня немного пугает, что сторонний продукт принимает решение о моем коде и изменяет его («Пожалуйста, не разбивайте мой код на две строки HAL. HAL?» ).

Тем не менее, я работаю в довольно небольшой команде, и все наши мониторы довольно большие, поэтому беспокойство по поводу того, что беспокоит моих коллег-программистов, не вызывает большого беспокойства.

Похоже, что некоторые языки поощряют использование более длинных строк кода ради большей отдачи (короткие операторы if then).

domusvita
источник
7

У меня есть два 20 "1600x1200 монитора, и я придерживаюсь 80 столбцов, потому что это позволяет мне отображать несколько окон текстового редактора бок о бок. Используя шрифт 6x13 (шрифт trad. Xterm), 80 столбцов занимают 480 пикселей плюс полоса прокрутки и границы окна. Это позволяет иметь три окна этого типа на мониторе 1600x1200. На окнах шрифт Lucida Console не вполне может это сделать (минимальный используемый размер составляет 7 пикселей в ширину), но монитор 1280x1024 будет отображать два столбца и монитор 1920x1200, например, HP LP2465 будет отображать 3. Он также оставит немного места сбоку для различных проводников, свойств и других окон из Visual Studio.

Кроме того, очень длинные строки текста трудно читать. Для текста оптимальным является 66 символов. Существует момент, когда чрезмерно длинные идентификаторы начинают приводить к обратным результатам, поскольку они затрудняют последовательное размещение кода. Хорошая компоновка и отступ обеспечивают визуальные подсказки относительно структуры кода, и некоторые языки (на ум приходит Python) явно используют отступ для этого.

Однако стандартные библиотеки классов для Java и .Net, как правило, имеют преобладание очень длинных идентификаторов, поэтому нельзя обязательно гарантировать, что это можно сделать. В этом случае размещение кода с переносом строк все еще помогает сделать структуру явной.

Обратите внимание, что вы можете получить версию для Windows шрифтов 6x13 здесь .

ConcernedOfTunbridgeWells
источник
Спасибо, что сказал это! Большие мониторы являются еще одной причиной ограничения 80 строк, поэтому вы можете разместить больше окон рядом друг с другом. Не говоря уже о том, что приятно иногда иметь возможность печатать исходный код (на бумаге). Или вставьте фрагменты в другие документы.
ныряет
7

Люди говорят, что длинные строки кода имеют тенденцию быть сложными. Рассмотрим простой класс Java:

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

Это 94 символа в длину, а название класса довольно короткое (по стандартам GWT). Было бы трудно читать на 2 строки, и это очень читаемо на одной строке. Будучи прагматичным в этом отношении и, таким образом, допуская «обратную совместимость», я бы сказал, что 100 символов - это правильная ширина.

Матиас
источник
5
Я не фанат горизонтальных полос прокрутки
bryc
9
Я удивлен, что никто не сказал этого, учитывая, что я несколько лет опаздываю к этому обсуждению, но я думаю, что новые строки (возможно, с отступом для ясности) прямо перед тем, как "расширяет" и / или "внедряет" ключевые слова, все равно будет очень читаемый код.
mtraceur
2
Мне нравится тот факт, что он говорит: «Он очень удобочитаемый в одной строке», и в то же время я не могу прочитать весь фрагмент кода, поскольку он переполняет горизонтальное пространство в браузере. Точка опровергнута.
oligofren
6

Другие ответы уже подытожили, но также стоит подумать, когда вы захотите скопировать и вставить некоторый код в электронное письмо, или, если не код, то diff.

Это время, когда полезно иметь максимальную ширину.

user14038
источник
6

Вы не единственный человек, который собирается поддерживать ваш код.

Следующий человек, у которого действительно может быть 17-дюймовый экран или могут потребоваться большие шрифты для чтения текста. Ограничение должно быть где-то, и 80 символов - это соглашение из-за предыдущих ограничений экрана. Можете ли вы вспомнить любой новый стандарт (120) и почему это хорошая идея, чтобы использовать это другое, то "это то, что подходит на моем мониторе с шрифтом Xpt?"

Помните, что к каждому правилу всегда есть исключения, так что если у вас есть конкретная строка или блок кода, который имеет смысл быть более 80 символов, а затем быть бунтовщиком.

Но сначала подумайте: «Неужели этот код настолько плох, что не может жить в пределах 80 символов?»

pappes
источник
1
Я буду жить с 80-ю символами, когда у меня будет 2 таба. Еще лучше, фактически использовать вкладки для отступа, требование заключается в том, что когда tabsize = 2, помещается в 80 столбцах, большую часть времени используется 4 для лучшей читаемости. Таким образом, когда вам действительно нужно подавиться до 80 столбцов, вы можете, но по цене.
Джошуа
5

В стандарте кодирования Linux они не только поддерживают ограничение в 80 символов, но также используют отступ в 8 пробелов.

Часть рассуждений заключается в том, что если вы когда-нибудь достигнете правильного поля, вам следует рассмотреть возможность перемещения уровня отступа в отдельную функцию.

Это сделает код более понятным, потому что независимо от длины отступов, сложнее читать код со многими вложенными управляющими структурами.

Али
источник
3
Как насчет чтения кода со многими вызовами функций? Конечно, есть компромисс между этими двумя подходами ...
Жолт Тёрёк
5

Я расширил свой код до 100 символов, что удобно помещается менее чем на половине моего экрана на моем Macbook. 120 символов - это, вероятно, предел, прежде чем строки станут слишком длинными и сложными. Вы не хотите становиться слишком широкими, иначе вы поощряете составные операторы и глубоко вложенные структуры управления.

Правильный запас - это естественный способ сказать вам, что нужно выполнить дополнительный метод рефакторинга .

Schwern
источник
5

Интересно, может ли это вызвать больше проблем в наши дни? Помните, что в C (и, возможно, в других языках) существуют правила относительно того, как долго может быть имя функции. Поэтому вы часто видите очень трудные для понимания имена в C-коде. Хорошо, что они не занимают много места. Но каждый раз, когда я смотрю на код на каком-то языке, таком как C # или Java, имена методов часто бывают очень длинными, что делает практически невозможным поддерживать ваш код длиной 80 символов. Я не думаю, что 80 символов действительны сегодня, если вам не нужно иметь возможность напечатать код и т. Д.

Jonas
источник
5

Как автор руководств по кодированию для моего работодателя, я увеличил длину строки с 80 до 132. Почему это значение? Ну, как и другие отмечали, 80 это длина многих старых аппаратных терминалов. И 132 тоже! Это ширина линии, когда терминалы находятся в широком режиме . Любой принтер может также делать печатные копии в широком режиме со сжатым шрифтом.

Причина не оставаться в 80 состоит в том, что я скорее

  • предпочитаю более длинные имена со значением для идентификаторов
  • не беспокойтесь о typedef для структур и перечислений в C (они ПЛОХО, они скрывают полезную информацию! Спросите Питера ван дер Линдена в "Deep C Secrets", если вы в это не верите), так что код имеет больше, struct FOO func(struct BAR *aWhatever, ...)чем просто код фанатиков typedef ,

и по этим правилам только 80 символов / строка вызывают появление уродливых переносов строк чаще, чем мои глаза считают приемлемым (в основном в прототипах и определениях функций).

Йенс
источник
4

Как уже говорили другие, я думаю, что это лучше всего для (1) печати и (2) отображения нескольких файлов рядом друг с другом по вертикали.

Томас Оуэнс
источник
4

Мне нравится ограничивать мою ширину до 100 символов или около того, чтобы на широкоэкранном мониторе можно было установить два редактора SxS. Я не думаю, что есть какая-либо веская причина для ограничения в 80 символов.

Джейми Эйзенхарт
источник
4

Используйте пропорциональные шрифты.

Я серьезно. Обычно я могу получить эквивалентность 100-120 символов в строке, не жертвуя удобочитаемостью или печатностью. На самом деле это даже легче читать с хорошим шрифтом (например, Verdana) и синтаксической раскраской. Это выглядит немного странно в течение нескольких дней, но вы быстро привыкаете к этому.

bgiles
источник
Действительно плохая идея, когда вы хотите использовать «отступы» и моноширинные шрифты.
Берсаэльор,
2
@Bersaelor Нет, он работает нормально, когда вы всегда делаете отступ, используя только вкладки, и правильно устанавливаете ширину вкладки (ширина 4 с одинарным интервалом примерно равна 7 пропорционально). Отступы работают, вы просто не можете сделать ASCII-арт, но я не думаю, что ASCII-арт принадлежит к коду.
Maaartinus
Лично я при программировании нахожусь на противоположной стороне. Я считаю, что пропорциональный код действительно трудно читать. Иногда я даже настраиваю IDE для использования моноширинных шрифтов (да, включая меню).
Себастьян Мах
2

Я пытаюсь сократить количество символов до 80 символов по одной простой причине: слишком много это означает, что мой код становится слишком сложным. Чрезмерно подробные имена свойств / методов, имена классов и т. Д. Наносят такой же вред, как и краткие.

Я в первую очередь программист Python, поэтому это создает два набора ограничений:

  1. Не пишите длинные строки кода
  2. Не отступать слишком много

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

В Python легко написать относительно лаконичный код (см. Codegolf) за счет читабельности, но еще проще написать подробный код за счет читабельности. Вспомогательные методы не так уж плохи, как и вспомогательные классы. Чрезмерная абстракция может быть проблемой, но это еще одна проблема программирования.

Если вы сомневаетесь в языке, подобном C, напишите вспомогательные функции и вставьте их в строку, если вы не хотите, чтобы накладные расходы вызывали другую функцию и возвращались назад. В большинстве случаев компилятор будет обрабатывать вещи разумно для вас.

Дэн Удей
источник
2

На это уже есть много хороших ответов, но стоит упомянуть, что в вашей IDE у вас может быть список файлов слева и список функций справа (или любая другая конфигурация).

Ваш код - это только одна часть среды.

Дин Скорее
источник
2

То, что я не выполняю 80 символов, означает перенос слов.
IMO, любая длина, выбранная для линии максимальной ширины, не всегда подходит, и перенос слов должен быть возможным ответом.
И это не так просто, как кажется.

Это реализовано в jedit (источник: jedit.org )альтернативный текст
который предлагает перенос слов

Но это очень упущено в затмении из долгого времени ! (фактически с 2003 года), главным образом потому, что перенос слов для текстового редактора включает в себя:

  • Информация обернутой строки предназначена для просмотра текста, навигации по коду, вертикальных линейок.
  • Информация об развернутой строке требуется для таких функций, как строка перехода, столбец линейки нумерации строк, выделение текущей строки, сохранение файла.
VonC
источник
1

На самом деле я придерживаюсь аналогичного правила для своего собственного кода, но только из-за печати кода на странице формата А4 - 80 столбцов примерно соответствуют ширине для моего желаемого размера шрифта.

Но это личное предпочтение и, вероятно, не то, что вы хотели (поскольку вы хотите, чтобы патроны пошли другим путем).

Что вы не оспариваете в обосновании предела - серьезно, если никто не может придумать вескую причину, почему это так, у вас есть веские основания для того, чтобы убрать его из ваших стандартов кодирования.

paxdiablo
источник
Я почти уверен, что это были времена, когда экраны в текстовом режиме имели ширину 80 символов.
TraumaPony
1

Я весь день провожу бок о бок, и у меня нет офигенного 22-дюймового монитора. Я не знаю, буду ли я когда-либо. Это, конечно, не представляет большого интереса для программистов только для записи, которым нравится кодирование стрелок и строки из 300 символов.

Constantin
источник
1

Да, потому что даже в наши дни некоторые из нас кодируют терминалы (в основном эмуляторы терминалов), где дисплей может отображать только 80 символов. Так что, по крайней мере, для кодирования, которое я делаю, я действительно ценю правило 80 символов.

CobolGuy
источник
0

Я все еще думаю, что предел не ограничен визуальной частью. Конечно, мониторы и разрешения достаточно велики, чтобы в настоящее время показывать еще больше символов в одной строке, но повышает ли это удобочитаемость?

Если ограничение действительно соблюдается, это также хорошая причина переосмыслить код и не помещать все в одну строку. То же самое с отступом - если вам нужно много уровней, ваш код необходимо переосмыслить.

Юнексист
источник
0

Разбивать 80 символов - это то, что вы делаете, пока кодирования, а не после. То же самое с комментариями, конечно. Большинство редакторов могут помочь вам увидеть, где находится ограничение в 80 символов.

(Это может быть немного OT, но в Eclipse есть опция, которая форматирует код при его сохранении (в соответствии с любыми правилами, которые вы хотите). Сначала это немного странно, но через некоторое время вы начинаете признавать, что форматирование не более в ваших руках, чем сгенерированный код.)

JesperE
источник
0

Если бы у нас был один из них , у нас не было бы этого обсуждения! ;-)

А если серьезно, то вопросы, которые люди поднимали в своих ответах, вполне законны. Однако оригинальный плакат не спорил против предела, просто 80 столбцов - это слишком мало.

Проблема отправки фрагментов кода по электронной почте имеет некоторые достоинства. Но учитывая то зло, которое большинство почтовых клиентов делают с предварительно отформатированным текстом, я думаю, что перенос строк - это только одна из ваших проблем.

Что касается печати, я обычно нахожу, что 100 строк символов очень удобно поместятся на печатной странице.

Эндрю Эджкомб
источник
0

Я стараюсь держать свои строки ниже 80 столбцов. Самая сильная причина в том, что я часто использую grepи lessпросматриваю свой код при работе в командной строке. Мне действительно не нравится, как терминалы ломают длинные строки исходного кода (они ведь не предназначены для этой работы). Другая причина в том, что я считаю, что это выглядит лучше, если все вписывается в строку и не нарушается редактором. Например, наличие параметров длинных вызовов функций, красиво выровненных друг под другом, и тому подобное.

Йоханнес Шауб - Литб
источник