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

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

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

вот же тему Slashdot.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

другие ответы уже суммировали вещи красиво, но также стоит рассмотреть, когда вы можете скопировать и вставить какой-то код в электронную почту, или если не код, то diff.

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

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

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

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

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

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

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

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

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

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

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

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

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

причина, по которой я не останавливаюсь в 80, заключается в том, что я скорее

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ваш код-это всего лишь одна часть окружения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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