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

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

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

Я думаю, что практика сохранения кода в 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).

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

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

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

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

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

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

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

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

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

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

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

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

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

Я расширил свой код до 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) и синтаксической раскраской. Это выглядит немного странно в течение нескольких дней, но вы быстро привыкаете к этому.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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