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

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


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

32 ответа

Решение

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

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

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

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

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

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

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

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

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

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

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

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

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

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 столбцов, я думаю, что моя точка зрения остается неизменной, и я просто выбрал плохой пример. Это все еще демонстрирует, что размещение нескольких операторов в строке может улучшить читаемость.

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

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

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

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

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

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

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

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

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

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

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

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

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

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

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

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

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

У меня есть два 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 здесь.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И около 17 лет назад я позволил своему собственному коду расшириться до 88 столбцов, потому что я начал делать все, используя Noweb, а 88 столбцов - это то, что вписывается в красиво напечатанный документ с использованием TeX.

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

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

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

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

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

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

Другие вопросы по тегам