Описательное именование против 80 строк символов [закрыто]

17

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

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

mjgpy3
источник
4
@BillyONeal с большими экранами, 120 :)
BЈовић
4
Я думаю, что мне нужно по крайней мере 130
9дан
8
Я предпочитаю 80, потому что я могу легко открыть 2 файла рядом на моем ноутбуке.
Хонза Брабек
5
Строки длиной более 80 символов становятся нечитаемыми. Так что 80 - это хороший предел. Описательный не должен быть слишком многословным. И это зависит от области применения: короткие имена переменных области действия, более длинные имена области действия. И во что бы то ни стало избегайте переменных с большой областью действия. Если вы работаете с ним, используйте функциональный язык и разбивайте свой код на более мелкие функции, когда он слишком сильно отступает -> очень малая область видимости == короткие имена переменных. Имена функций похожи, но обычно немного длиннее, потому что их область действия больше.
Peer Stritzinger
4
@ ott--: Вы видели редактор, который может на самом деле разбить длинную строку, в соответствии с синтаксисом C ++, и представить продолжение с отступом еще на один уровень, чем в начале? В противном случае такое предложение бесполезно.
Ян Худек

Ответы:

34

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

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

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

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

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

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

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

Craige
источник
3
Следует отметить, что описательные имена не совпадают с длинными именами. Избегание повторения вещей, которые можно легко увидеть из контекста и нескольких тщательно отобранных сокращений (только для очень распространенных понятий), может иметь большое значение для коротких описательных имен.
Ян Худек
18

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

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

tdammers
источник
1
+1: Отличный ответ, за исключением того, что я не согласен с удалением литералов из кода. Когда вы знаете, какой литерал вы ищете, вы можете одинаково хорошо использовать его в ресурсах или коде, но когда вы работаете с кодом и вам нужно модифицировать литерал, необходимость отыскивать его в отдельном файле довольно отвлекает. Также обратите внимание, что у всех языков есть некоторый способ разделения литералов на несколько строк, что я и сделал бы в таком случае.
Ян Худек
Конечно, предложение, используемое в качестве примера длинного литерала, не имеет места в исходном коде. Такие вещи идут в шаблонах страниц. Но для таких вещей, как сообщения об ошибках, я предпочитаю хранить их с кодом, который их генерирует.
Ян Худек
@JanHudec: Конечно, перемещение литералов в файл данных не всегда имеет смысл. Я говорю о слишком длинных литералах, и с ними я редко видел случай, когда их определение в другом месте могло бы ухудшить код: длина текста мешает чтению, в то время как значение этого может быть легко сжатый в постоянное или переменное имя, которое вы затем определяете в другом месте. Я полагаю, сообщения об ошибках являются оценочным.
tdammers
16

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

Мэтт С
источник
2
Эта. Прекратите разбивать строки на символах X, пусть IDE справится с этим. В противном случае вы беспокоите всех других пользователей (включая будущих вас!), Чьи экраны / IDE могут обрабатывать символы 2 * X с кодом, который больше не помещается на одной странице.
Конерак
4
Вопрос был неявно о длинных именах, хотя. И я не согласен с тем, что имена должны быть длинными - в большинстве случаев они должны быть короткими . Описательные, длинные имена могут сделать код более трудным для чтения, чем чуть менее описательные, но более короткие имена! (Чрезмерно длинные строки обычно трудно читать.)
Конрад Рудольф
4
Я не согласен. Если я не вижу код сразу, его трудно прочитать, независимо от того, насколько понятны названия.
Ян Худек
4

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

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

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

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

нео
источник
2
80 символов действительно улучшают читабельность? Какой экран не может легко сделать 120 в эти дни?
Билли Онил
7
@BillyONeal легче сканировать шириной более 80, чем шириной более 120
трещотка урод
2
новостная газета разбивается на столбцы, и вы можете получить дополнительную информацию с сайта
neo
1
Разбиение логического условия улучшает читабельность, когда разрывы строк соответствуют структуре условия, но не обязательно, если они только соответствуют некоторому произвольному пределу.
Миколак
1
@BillyONeal: большинство экранов может сделать 120, но вряд ли кто-то может сделать 240. Или вы никогда не сравниваете diff?
Хьюберт Карио
0

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

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

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

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

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

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

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

Sulthan
источник
4
Нет, предел определенно не должен быть увеличен. Поскольку это не имеет ничего общего с технологией экрана и печати, только тот факт, что 80 символов в строке - это максимальный человеческий глаз, позволяет комфортно сканировать (66 символов считается оптимальной шириной линии, меньше при многостолбцовой печати). Что, кстати, означает, что в большинстве книг есть не более 80 столбцов для примеров кода.
Ян Худек
3
@JanHudec Это все, что связано с технологией экрана / печати. См. Programmers.stackexchange.com/questions/148677/… . Решение использовать 80 символов чисто историческое, не основанное на исследованиях. Не могли бы вы добавить ссылки на исследования, чтобы подтвердить свое мнение?
Sulthan
Другой вопрос уже получил эту ссылку UX в своих комментариях; дальнейшие ссылки там. Хотя само число 80 является историческим совпадением, оно примерно получено из числа ударов на строку на печатных машинках, которое было примерно получено из общей ширины одностолбцовой печати, и среднее значение из 66 букв было давней традицией для этого.
Ян Худек