Есть ли веская причина для обеспечения максимальной ширины 80 символов в файле кода в наши дни?[закрыто]
https://stackoverflow.com/questions/110928
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Серьезно.На 22-дюймовом мониторе он занимает примерно четверть экрана.Мне нужны кое-какие боеприпасы, чтобы нарушить это правило.
Я не говорю, что не должно быть предела;Я просто говорю, что 80 символов - это очень мало.
Решение
Я думаю, что практика хранения кода в 80 (или 79) столбцах изначально была создана для поддержки людей, редактирующих код на тупых терминалах с 80 столбцами или на распечатках с 80 столбцами.Сейчас эти требования в основном отменены, но все еще есть веские причины сохранить правило 80 столбцов:
- Чтобы избежать переноса при копировании кода в электронную почту, веб-страницы и книги.
- Для одновременного просмотра нескольких окон с исходным кодом или с помощью параллельного средства просмотра различий.
- Для улучшения читабельности.Узкий код можно быстро прочитать, не водя глазами из стороны в сторону.
Я думаю, что последний пункт самый важный.Хотя за последние несколько лет размеры и разрешение дисплеев выросли, глаза еще не.
Другие советы
Форматирование текста на 80 столбцов появилось раньше, чем терминалы на 80 столбцов - перфокарта IBM появилась в 1928!Это напоминает о (апокрифический) история о том, что ширина железнодорожной колеи в США определялась шириной колес колесниц в Римской Британии.
Иногда я нахожу это немного стеснительным, но имеет смысл иметь некоторые стандартный лимит, то есть 80 столбцов.
Вот та же тема, что и в Слэшдот.
А вот заявление старой школы Fortran:
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 мог бы сделать это за меня, но тогда меня немного пугает, что сторонний продукт принимает решения по моему макету кода и изменяет его ("Пожалуйста, не разбивайте мой код на две строки, ХЭЛ.ХЭЛ?").
Тем не менее, я работаю в довольно небольшой команде, и все наши мониторы довольно большие, так что беспокоиться о том, что беспокоит моих коллег-программистов, не стоит.
Похоже, что некоторые языки поощряют более длинные строки кода ради большей отдачи (короткие инструкции if then).
У меня есть два монитора с диагональю 20 дюймов 1600x1200, и я использую 80 столбцов, потому что это позволяет мне отображать несколько окон текстового редактора бок о бок.Используя шрифт "6x13" (традиция.шрифт xterm) 80 столбцов занимают 480 пикселей плюс полоса прокрутки и границы окна.Это позволяет иметь три окна такого типа на мониторе с разрешением 1600x1200.В Windows консольный шрифт Lucida не совсем подходит для этого (минимальный используемый размер составляет 7 пикселей в ширину), но на мониторе с разрешением 1280x1024 будут отображаться две колонки, а на мониторе с разрешением 1920x1200, таком как HP LP2465 отобразится 3.Это также оставит немного места сбоку для различных проводников, свойств и других окон Visual Studio.
Кроме того, очень длинные строки текста трудно читать.Для текста оптимально использовать 66 символов.Наступает момент, когда чрезмерно длинные идентификаторы начинают быть контрпродуктивными, потому что они затрудняют связное изложение кода.Хорошая компоновка и отступы дают визуальные подсказки относительно структуры кода, и некоторые языки (на ум приходит Python) явно используют отступы для этого.
Однако стандартные библиотеки классов для Java и .Net, как правило, имеют преобладание очень длинных идентификаторов, поэтому никто не может гарантировать, что сможет это сделать.В этом случае размещение кода с разрывами строк по-прежнему помогает сделать структуру явной.
Обратите внимание, что вы можете получить версии шрифтов "6x13" для Windows Здесь.
Другие ответы уже хорошо подвели итог, но также стоит подумать, когда вы, возможно, захотите скопировать и вставить какой-то код в электронное письмо, или если не код, то разницу.
Это тот случай, когда полезно иметь "максимальную ширину".
Вы не единственный человек, который собирается поддерживать ваш код.
У следующего человека, который это сделает, может быть 17-дюймовый экран или ему могут понадобиться крупные шрифты для чтения текста.Предел должен быть где-то, и 80 символов - это соглашение из-за предыдущих ограничений экрана.Можете ли вы вспомнить какой-нибудь новый стандарт (120) и почему было бы неплохо использовать именно его, а не "это то, что помещается на моем мониторе шрифтом Xpt"?
Помните, из каждого правила всегда есть исключения, поэтому, если у вас есть определенная строка или блок кода, в котором имеет смысл содержать более 80 символов, тогда будьте бунтарем.
Но сначала найдите время подумать: "действительно ли этот код настолько плох, что не может вместить 80 символов?"
В стандарте кодирования Linux они не только сохраняют ограничение в 80 символов, но и используют отступ в 8 пробелов.
Отчасти это объясняется тем, что если вы когда-нибудь достигнете нужного поля, вам следует рассмотреть возможность переноса уровня отступа в отдельную функцию.
Это сделает код более понятным, потому что независимо от длины отступов, читать код с большим количеством вложенных управляющих структур сложнее.
Интересно, может ли это вызвать еще больше проблем в наши дни?Помните, что в C (и, возможно, в других языках) существуют правила, определяющие, какой длины может быть имя функции.Поэтому вы часто видите очень трудные для понимания имена в коде на языке Си.Хорошо то, что они не занимают много места.Но каждый раз, когда я смотрю на код на каком-нибудь языке, таком как C # или Java, имена методов часто бывают очень длинными, что делает практически невозможным сохранение длины вашего кода в 80 символов.Я не думаю, что 80 символов допустимы сегодня, если только вам не нужно иметь возможность распечатать код и т.д.
Как говорили другие, я думаю, что это лучше всего подходит для (1) печати и (2) отображения нескольких файлов рядом по вертикали.
Мне нравится ограничивать ширину до 100 символов или около того, чтобы разрешить использование двух редакторов SxS на широкоэкранном мониторе.Я не думаю, что теперь есть какие-либо веские причины для ограничения ровно в 80 символов.
Я расширил свой код до 100 символов, который удобно умещается менее чем на половине экрана моего Macbook.120 символов - это, вероятно, предел, прежде чем строки начнут становиться слишком длинными и сложными.Вы не хотите становиться слишком широкими, иначе вы поощряете составные операторы и глубоко вложенные структуры управления.
Правое поле - это способ природы подсказать вам, что нужно выполнить рефакторинг дополнительного метода.
Используйте пропорциональные шрифты.
Я серьезно.Обычно я могу получить эквивалентность 100-120 символов в строке без ущерба для удобочитаемости или возможности печати.На самом деле его даже легче читать с хорошим шрифтом (например, Verdana) и синтаксической раскраской.Несколько дней это выглядит немного странно, но вы быстро к этому привыкаете.
Люди говорят, что длинные строки кода, как правило, сложны.Рассмотрим простой класс Java:
public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {
Это имя состоит из 94 символов, а название класса довольно короткое (по стандартам GWT).Это было бы трудно прочитать в 2 строки, и это очень легко читается в одной строке.Будучи прагматичным в этом вопросе и, таким образом, обеспечивая "обратную совместимость", я бы сказал, что 100 символов - это правильная ширина.
Как автор руководства по кодированию для моего работодателя, я увеличил длину строки с 80 до 132.Почему это значение?Ну, как указывали другие, 80 - это длина многих старых аппаратных терминалов.И 132 - это тоже хорошо! Это ширина линии, когда терминалы находятся в широкий режим.Любой принтер также может делать печатные копии в расширенном режиме с сокращенным шрифтом.
Причина, по которой я не останавливаюсь на отметке 80, заключается в том, что я скорее
- предпочитайте более длинные имена со значением для идентификаторов
- не утруждайте себя определениями типов для структур и перечислений в C (они ПЛОХИЕ, они СКРЫВАЮТ полезную информацию!Спросите Питера ван дер Линдена из "Глубоких секретов языка Си", если вы в это не верите), так что в коде больше
struct FOO func(struct BAR *aWhatever, ...)чем код фанатиков typedef.
и в соответствии с этими правилами всего 80 символов на строку приводят к уродливому переносу строк чаще, чем я считаю приемлемым (в основном в прототипах и определениях функций).
Я стараюсь писать не более 80 символов по простой причине:слишком многое другое означает, что мой код становится слишком сложным.Чрезмерно подробные имена свойств / методов, имена классов и т.д.наносят такой же вред, как и немногословные.
Я в первую очередь программист на Python, так что это приводит к двум наборам ограничений:
- Не пишите длинные строки кода
- Не делайте слишком больших отступов
Когда вы начинаете достигать двух или трех уровней отступов, ваша логика становится запутанной.Если вы не можете сохранить один блок на одной странице, ваш код становится слишком сложным для запоминания.Если вы не можете вместить ни одной строки в 80 символов, ваша строка становится чрезмерно сложной.
В Python легко написать относительно краткий код (см. codegolf) в ущерб удобочитаемости, но еще проще написать подробный код в ущерб удобочитаемости.Вспомогательные методы - это неплохая вещь, как и вспомогательные классы.Чрезмерная абстракция может быть проблемой, но это еще одна проблема программирования.
Если вы сомневаетесь в таком языке, как C, напишите вспомогательные функции и встроите их, если вы не хотите накладных расходов, связанных с вызовом другой функции и возвратом назад.В большинстве случаев компилятор будет разумно обрабатывать данные за вас.
На этот вопрос уже есть много хороших ответов, но стоит упомянуть, что в вашей IDE у вас может быть список файлов слева, а список функций справа (или любая другая конфигурация).
Ваш код - это всего лишь одна из частей среды.
Я думаю, что отсутствие принудительного использования 80 символов означает, в конечном счете, перенос слов.
ИМО, любая длина, выбранная для строки максимальной ширины, не всегда уместна, и перенос слов должен быть возможным ответом.
А это не так просто, как кажется.
Это реализовано в jedit
(источник: jedit.org) который предлагает перенос слов
Но это так горько скучал по eclipse с давних пор !(фактически с 2003 года), главным образом потому, что перенос слов в текстовый редактор включает в себя:
- Информация о обернутых строках предназначена для просмотра текста, навигации по коду, вертикальных линеек.
- Развернутая информация о строке необходима для таких функций, как переходная строка, столбец линейки нумерации строк, выделение текущей строки, сохранение файла.
На самом деле я следую аналогичному правилу для своего собственного кода, но только из-за печати кода на странице формата А4 - 80 столбцов - это примерно правильная ширина для моего желаемого размера шрифта.
Но это личные предпочтения и, вероятно, не то, что вам было нужно (поскольку вы хотите, чтобы боеприпасы шли другим путем).
Что бы вы ни делали, не подвергайте сомнению обоснование ограничения - серьезно, если никто не может привести вескую причину, почему это так, у вас есть веские основания для его удаления из ваших стандартов кодирования.
Я целый день сижу бок о бок, и у меня нет долбаного 22-дюймового монитора.Я не знаю, смогу ли когда-нибудь.Это, конечно, малоинтересно программистам, ориентированным только на запись, которым нравится кодирование со стрелками и строки из 300 символов.
Да, потому что даже в наши дни некоторые из нас программируют на терминалах (ок, в основном на эмуляторах терминалов), где дисплей может отображать только 80 символов.Итак, по крайней мере, в том, что касается кодирования, которым я занимаюсь, я действительно ценю правило 80 символов.
Я все еще думаю, что ограничение не распространяется на визуальную часть.Конечно, в наши дни мониторы и разрешения достаточно велики, чтобы отображать еще больше символов в одной строке, но повышает ли это читабельность?
Если ограничение действительно введено в действие, это также хорошая причина переосмыслить код и нет поместить все в одну строку.То же самое и с отступами - если вам нужно значительно выровнять ваш код, его необходимо переосмыслить.
Разрыв на 80 символов - это то, что вы делаете в то время как кодирование, а не потом.То же самое, конечно, и с комментариями.Большинство редакторов могут помочь вам определить, где находится ограничение в 80 символов.
(Это может быть немного нестандартно, но в Eclipse есть опция, которая форматирует код при его сохранении (в соответствии с любыми правилами, которые вы хотите).Поначалу это немного странно, но через некоторое время вы начинаете соглашаться с тем, что форматирование находится в ваших руках не больше, чем сгенерированный код.)
Если бы у нас был один из эти, - мы бы не затевали эту дискуссию!;-)
Но если серьезно, то вопросы, которые люди поднимали в своих ответах, вполне законны.Однако первоначальный плакат не возражал против ограничения, просто утверждал, что 80 колонок - это слишком мало.
Проблема отправки фрагментов кода по электронной почте имеет некоторые преимущества.Но, учитывая ужасные вещи, которые большинство почтовых клиентов вытворяют с предварительно отформатированным текстом, я думаю, что перенос строк - лишь одна из ваших проблем.
Что касается печати, я обычно нахожу, что 100 символьных строк будут очень удобно помещается на печатной странице.
Я стараюсь, чтобы мои строки были ниже 80 столбцов.Самая веская причина заключается в том, что я часто ловлю себя на том, что использую grep и less просматривать мой код при работе в командной строке.Мне действительно не нравится, как терминалы разрывают длинные исходные строки (в конце концов, они не созданы для такой работы).Другая причина заключается в том, что я нахожу, что это выглядит лучше, если все вписывается в строку и не нарушается редактором.Например, чтобы параметры длинных вызовов функций были красиво выровнены друг под другом и тому подобное.
