Я часто слышу эти две полезные практики программирования: (1) строки кода должны быть длиной не более 80 символов и (2) использовать описательные имена для переменных, методов, классов и т. Д. Я понимаю причину обоих этих советов, однако кажется, что они часто являются компромиссами друг с другом. Если я оставлю код ниже 80 символов / строку, я получу менее описательные имена (особенно в Python, в котором каждый отступ считается как 4 символа), но если я использую больше описательных имен, я получу строки длиной более 80 символов.

Итак, мой вопрос: какой из этих двух советов важнее соблюдать, если выбор должен быть сделан? Мне интересно это как независимый (любитель) программист, но что более важно с точки зрения инженера-программиста, работающего в более крупной компании.

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

Держите свои отступы немного.

Часто, когда я нахожусь в борьбе между отступами и описательными именами, я делаю шаг назад и смотрю на свой уровень отступа. Если вы делаете отступ более чем на 3 или 4 уровня (во многих случаях 2 уровня являются автоматическими и неизбежными. Прочтите: определение метода класса), вы можете реструктурировать свой код, абстрагируя функциональность от функции или метода.

Ваши имена описательны

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

Не бойся нарушать черту

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

Почему не оба?

Прежде всего, «описательный» и «многословный» не одно и то же. Например, если вы пишете довольно локальный цикл, iэто очень хорошее имя переменной для переменной цикла; current_iteration_indexхотя, возможно, более описательный и определенно более многословный, он намного хуже и вообще не добавляет никакой информации, потому что использование iв качестве переменной цикла является общепринятым, и другого смысла в iэтом нет.

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

Ограничение в 80 символов, хотя первоначально оно было следствием технических ограничений текстовых терминалов 1970-х годов, по-прежнему ценится многими сегодня, и хотя есть все еще технические причины (максимальная длина строки в некоторых сетевых протоколах, в особенности связанных с электронной почтой), более веские причины - психологические и социальные. Оказывается, что длина строки около 66-символьной метки обеспечивает удобство чтения для проза на естественном языке (интересный размер шрифта не имеет большого значения, и, следовательно, размер экрана или бумаги); Пределы строки в 80 символов довольно близки к этому, но, поскольку основная часть типичного фрагмента кода обычно имеет отступ не менее одного или двух уровней (что означает от 4 до 16 символов в зависимости от настроек отступа),

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

• Функции с длинным списком аргументов; это нехорошо, потому что они ухудшают читабельность и могут легко вызывать незначительные ошибки, например, когда люди меняют порядок аргументов так, что компилятор не улавливает их.
• Сложные выражения, часто встречающиеся в условных выражениях (например if ((user.isLoggedIn && user.hasPermission(page.getRequiredPermission()) && !user.isBanned) || page.getRequiredPermission() == null)); это тоже обычно довольно сложно расшифровать, и код должен быть переписан во что-то более структурированное. Скорее всего, выражение делает слишком много и должно быть вынесено в метод или функцию.
• Длинные литералы, используемые в вызовах функций или выражениях, например print(translate(LANG_EN, LANG_ES, "This is the home page. Feel welcome to click around and see what we have.")); . Переместить литерал в переменную или константу; он все равно может превышать длину строки, но если вы делаете это последовательно, читатель может, по крайней мере, безопасно игнорировать невидимую часть строки, предполагая, что следует только остаток литерала. Или, что еще лучше, переместите литералы из кода во внешнее хранилище данных (файл, база данных и т. Д.).
• Глубоко вложенные операторы, например, шесть уровней ifоператоров в методе класса (это 32 столбца отступа для типичных настроек). Опять же, глубокое вложение создает сложный и трудно читаемый код, и его следует избегать, как чумы - проще говоря, глубокое вложение переполняет стек человеческого мозга при чтении.

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

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

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

if ( a == b || c == d  || d == e
    || c == e || c == a || c == k
    || c == l)

Вы также можете разделить строку вызова функций на несколько строк.

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

80 предел - это то, что должно было быть увеличено давным-давно. Обратите внимание, что этот предел используется с возраста, когда длина каждого идентификатора была ограничена 8 символами и только одним шрифтом на экране / принтере. Нет возможности изменить размер шрифта.

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

Даже тогда это не должно быть жестким ограничением. Вы идете один символ за линию? Ну, ничего не происходит!

Редактировать:

Подробные ответы об истории 80-символьного лимита

Персонажи на линию в Википедии

Исследование, проведенное в Университете штата Уичито, показало, что CPL оказывает лишь незначительное влияние на читабельность, включая факторы скорости и понимания. Однако, когда его спросили о предпочтениях, 60% респондентов указали предпочтение либо самой короткой (35 CPL), либо самой длинной (95 CPL) линиям, использованным в исследовании. В то же время, 100% респондентов выбрали одну из этих величин как наименее желательную.