Подтвердить что ты не робот

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

Ответ 2

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

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

Здесь тот же самый раздел, посвященный Slashdot.

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

FORTRAN punch card

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

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

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

Ответ 9

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

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

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

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

Ответ 10

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

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

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

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

Ответ 11

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

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

Ответ 12

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

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

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

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

Ответ 13

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

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

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

Ответ 14

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

Ответ 15

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

Причина того, что я не останусь в 80, - это то, что я скорее

  • предпочитает более длинные имена со значением для идентификаторов
  • не беспокоиться о typedefs для structs и enums в C (они BAD, они HIDE полезная информация! Спросите Peter van der Linden в "Deep C Secrets", если вы не верите), поэтому код имеет больше struct FOO func(struct BAR *aWhatever, ...) чем код фанатиков typedef.

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

Ответ 16

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

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

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

Ответ 17

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

Ответ 18

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

Ответ 19

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

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

Ответ 20

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

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

Ответ 21

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

Он реализован в jedit alt text http://www.jedit.org/images/logo64.png, который предлагает перенос слов

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

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

Ответ 22

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

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

  • Не записывайте длинные строки кода
  • Не слишком сильно отступать

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

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

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

Ответ 23

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

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

Ответ 24

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

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

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

Ответ 25

Я целый день бок о бок, и у меня нет 22-дюймового монитора freakin. Я не знаю, смогу ли я когда-нибудь это сделать. Это, конечно, малоинтересно для программистов, использующих только стрелки, и со стрелками и 300- char.

Ответ 26

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

Ответ 27

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

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

Ответ 28

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

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

Ответ 29

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

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

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

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

Ответ 30

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