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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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