Исследования оптимальной ширины кода?

У меня нет исследований, но я свяжу свой опыт.

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

, Например, когда я работал в Emacs над XWindows, он работал хорошо, чтобы иметь 2 окна Emacs бок о бок в любом случае. Это ограничило их 80 символами, так, чтобы была моя макс. длина строки.

Однажды я работал в Visual Studio над 1920x1200 экран. Я сохранил бы максимизируемым со всеми окнами инструментов прикрепленный вниз одна сторона. Было достаточно пространства, уехал в два окна редактора бок о бок приблизительно в 100 символах.

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

, Если Вы & Ваши co-программисты имеют экраны с высоким разрешением и резкое зрение, любой ценой используют мелкий шрифт и длинные линии. С другой стороны Вам, возможно, понадобятся короткие строки.

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

Причины предпочесть 80:

• Читаемый с большим шрифтом на ноутбуках

• Уезжает, пространство для помещения двух версий рядом для сравнения

• Уезжает, пространство для представлений навигации в Печати IDE

• , произвольно не повреждая строки (также относится к электронной почте, веб-страницам...)

• Пределы сложность в одной строке

• Предельное добавление отступа, которое в свою очередь ограничивает сложность методов / функции

Да, это должна быть часть стандарта кодирования.

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

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

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

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

Насколько я знаю 80 символов используются в качестве стандарта кодирования для поддержания совместимости с редакторами командной строки (терминальная ширина по умолчанию обычно является 80 символами). С современными IDE и разрешениями с большим экраном 80 символов, вероятно, не "оптимальны", но для многих разработчиков, поддерживающих удобочитаемость в терминале, важно. По этой причине маловероятно, что 80 ширины символов будет заменена в качестве фактического стандарта для ширины кода в ближайшее время. И отвечать на Ваш заключительный вопрос, да, ширина кода, а также любая другая характеристика, которая будет влиять на удобочитаемость Вашего кода, должна быть обращена в Ваших стандартах кодирования.

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

object.getFoo().getBar().getFooBar().get ...

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

Кроме того, 80 символов - это здорово, как упоминал starblue. Это определенно должно входить в стандарты кодирования.

Обычно я использую 120-150, если в компании не указано иное. Однако это зависит и от типа кода:

• Я (почти) никогда не использую несколько утверждений на одной строке
• Я использую длинные строки (>12), только если строки, которые выглядят одинаково, можно выровнять и не разрывать.
• Я всегда использую достаточно пробелов/прозрачных тезисов и т.д.
• Я предпочитаю длинные имена переменных более коротким

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

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