Короткие идентификаторы плохие? [закрыто]

Короткие идентификаторы плохие? Как длина идентификатора соотносится с пониманием кода? Какие другие факторы (помимо понимания кода) могут иметь значение при именовании идентификаторов?

Просто чтобы сохранить качество ответов, обратите внимание, что уже есть некоторые исследования по этому вопросу!

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

Любопытно, что все или не считают длину релевантной, или предпочитают большие идентификаторы, когда обе ссылки, которые я указал, указывают на большие идентификаторы, которые вредны

Неработающей ссылке

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

• http://evergreen.loyola.edu/chm/www/Papers/SCP2009.pdf

Лучшее «правило», которое я слышал, это то, что длина имени должна быть пропорциональна длине области видимости переменной. Так что с индексом iвсе в порядке, если тело цикла состоит из нескольких строк, но мне нравится использовать что-то более описательное, если оно длиннее 15-ти строк.

Каждая переменная должна иметь значение, и ее имя является частью этого значения. И очень важная часть, поскольку она помогает читателю понять, для чего он нужен, не углубляясь в алгоритм. i, jочевидно, будут использоваться в качестве индексов, они короткие, но очень информативные. bntнекрасиво closeили closeButtonимеет смысл. Поэтому короткое или длинное не является самым важным критерием для имени переменной, оно должно быть осмысленным. Значимость сильно зависит от контекста. Например, вы можете дать очень короткое имя, подобное nлокальной строковой переменной, которая используется в небольшом блоке кода, скажем, 10 строк, и ссылается на имя свойства ( vдля значения это еще один пример).

Поэтому имена переменных должны быть информативными, и не важно, короткие они или длинные .

Я буду использовать идентификатор, который описывает переменную, независимо от длины.

Случаи i, j и k сами по себе настолько повсеместны, что самоописываются, вы автоматически знаете, что они являются индексами цикла. Вы также можете сказать то же самое для:

foreach loop (Strings s : myString)

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

Я с радостью добавлю и дополнительное слово к идентификатору, если это потребуется для объяснения назначения переменной.

Они не так плохи, как вводящие в заблуждение идентификаторы. Я не возражаю против отладки кода, в котором идентификаторы представляют собой только одну букву, но в тот момент, когда на картинке появляются разные соглашения об именах, это становится раздражающим. Например, если где-то вы видите strPersonID, а затем где-то еще видите s_EmployeeID, тогда сложно понять, являются ли эти две строки и есть ли какая-либо разница. Также, если переменные будут скопированы ( pmapIntString = new std::map<int,int>) и будут абсолютно неверными, я буду беспокоиться.

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

Я борюсь ...

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

Я думаю, это зависит от контекста кода:

• Если вы пишете сложные функции (алгоритмы), то ВСЕГДА используйте короткие идентификаторы (лучше всего использовать одиночные символы)
• При записи значений параметров для функций используйте описательные имена.

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

Иногда без имен это совершенно загадочно!

Я думаю, что они не плохие сами по себе, но они неинформативны, если они не очень стандартны.

Таким образом, переменные цикла, являющиеся i, j и k , настолько стандартны, что нет причин не использовать их, если вы создаете индексированный цикл.

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

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

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

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

Очень короткое имя переменного только полезно , если у него есть история , что делает его доступным (например, i, j, и kдля индексов, dxна расстояние вдоль оси) или объем , который достаточно мало , чтобы все ссылки , чтобы быть видимыми одновременно (например , , temp). Худшие имена переменных в мире - это что-то вроде t47. («Что это значит и чем оно отличается t46?») Слава Богу, стиль именования в основном был реализован в FORTRAN, но именно здесь укоренилось желание иметь более длинные имена переменных.

Как показала ваша оригинальная статья, слишком длинные имена также трудно читать, поскольку при взгляде на код можно пропустить тонкие внутренние различия. (Разницу между DistanceBetweenXAxisAbscissae& DistanceBetweenYAxisAbscissaeочень сложно быстро определить.)

Как NoteToSelf указывал ранее, требования к уникальности имени зависят, прежде всего, от области, в которой имя должно быть уникальным. Индекс цикла из 5 строк может быть i; индекс активной записи, который передается от функции к функции, должен иметь гораздо более описательное имя.

Локальная для функции переменная может иметь небольшое описательное имя, как deltaXбез проблем. Статическая переменная delta X в модуле должна иметь имя, которое отличает этот deltaX от других deltaX в том же модуле, делая его длиннее. И глобальная переменная дельта-X должна быть уникальной для всех модулей и всех возможных других модулей, которые могут быть созданы, возможно, путем объединения имени модуля с другим описательным именем. Это одна из многих проблем с глобалами; чтобы быть полезными, имена должны быть достаточно длинными, чтобы их было трудно читать.

Наоборот, я думаю, что длинные идентификаторы хуже, чем короткие идентификаторы (если вы не имеете дело с константами). Использование TheVariableThatHoldsTheCapacityOfMyContainerClassделает ваш код намного более подверженным ошибкам, чем использование Capacity.

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

Наблюдение, которое у меня было на протяжении многих лет, и сегодня оно меньше, чем 10-15 лет назад. Программисты, которые не умеют печатать, - это те, кто будет сражаться изо всех сил за переменное наименование. Они со всеми именами переменных 1-3 буквы.

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

Первая статья, на которую вы ссылаетесь, выглядит интересной, но ее вывод состоит в том, что они не нашли существенных доказательств за или против гипотезы о том, что «основательные намеки», включая значимые имена переменных, помогают в понимании кода. Используемое время ожидания взгляда в качестве прокси для понимания кода, что интересно, но не хлам.

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

Что еще более важно, их эксперимент является тестом простого запоминания, а не понимания. Он проверяет способность субъектов заполнять недостающие фрагменты имени переменной, когда они представлены в списке без контекста. Да, более длинные имена труднее запомнить, но когда я пишу код, я не запоминаю имена переменных, я использую их для обеспечения контекста. Я полагаю, вы могли бы возразить, что трудность запоминания длинной переменной делает код труднее писать, но код читается гораздо чаще, чем пишется, поэтому какую деятельность следует оптимизировать?

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

Легко сказать, что «любой должен понимать, что i, j и k являются переменными цикла». И в большинстве случаев это действительно очевидно. Но я все еще стараюсь быть скромным и профессиональным в этом и предполагаю, что при программировании легко ошибаться. Так что если я перебираю массив Grobbles, я назову переменную цикла grobbleIndex. Я также мог принять I как сокращение индекса. Когда вы используете ij и k, сложнее обнаружить ошибку, например, использовать неправильный индекс с неправильным массивом и так далее. И это становится еще хуже, когда у вас есть внутренний цикл.

PS. В то время, когда я писал этот ответ, я кодировал некоторый javascript на 10 "мини-ноутбуке с вертикально разделенным экраном в vim, и я все еще находил время, чтобы назвать свои переменные цикла rowIndex и columnIndex.

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

Я думаю, что в идеале имена должны быть описательными, если только ...

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

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

Я никогда не использовал бы имена идентификаторов длиной менее 4-5 символов, например, переменная цикла могла бы быть Index или jIndex или kIndex, в зависимости от того, сколько внутренних циклов мне нужно для выполнения чего-либо, но для других имен, скажем, «ключ», который я бы использовал «String LKey» или «int LKey», «L» для local, если это переменная метода, или «F» для переменной частного класса, все другие идентификаторы, как и другие, упомянутые выше, должны объяснять причину его существования в своем имени, в противном случае Область «идентификатора» бесполезна, не так ли ?!