Как многословность идентификаторов влияет на производительность программиста?

Ответ 1

Сокращения налагают на читателя гораздо большее бремя. Они неоднозначны; они косвенны; их труднее различать. Они тоже обременяют писателя, потому что он/она всегда должен спрашивать: "Это был Cmd для Command, или Cmnd... или Cm?". Они сталкиваются - данное правило аббревиатуры может вызывать ту же аббревиатуру для двух (или более) разных слов.

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

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

Ответ 2

Я пошла бы на ясность по многословию или бревиту.

ClearScreen() 

легче разобрать, чем

clrscr() 

по-моему, но

ClearScreenBeforeRerenderingPage() 

- просто шум.

Ответ 3

Конечно, разработчики .NET должны следовать .NET Naming Guidelines.

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

Не используйте сокращения или сокращения как части имен идентификаторов. Например, используйте GetWindow вместо GetWin.

Ответ 4

Лично мне нравится пробовать следовать мудрости Clean Code от дяди Боба.

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

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

Ответ 5

Я помню разговор от Ларри Уолла некоторое время назад, где он говорил о многословии идентификаторов, когда у вас в вашей команде есть неродные англоговорящие.

ClearScreenBeforeRerenderingPage()

отлично разбирается, если вы являетесь носителем английского языка. Однако он предлагает (и показывает опыт), что:

Clear_Screen_Before_Rerendering_Page()

намного лучше.

Эффект усугубляется, если вы не используете верхний и нижний регистр.

Ответ 6

Мое основное правило: каждая строка кода записывается только один раз, но читается 10, 100 или 1000 раз. В соответствии с этим усилие набора текста совершенно не имеет значения. Все, что имеет значение, - это попытка прочитать что-то.

Конечно, это само по себе все еще оставляет достаточно места для субъективных мнений (достаточно clrscrn?), но по крайней мере сужает поле как-то.

Ответ 7

Пожалуйста, перейдите непосредственно к соответствующей главе Стив Макконнелл "Code Complete" (санированная ссылка Amazon).

В частности, глава 11 "Сила переменных имен".

Ответ 8

Мои личные предпочтения состоят в том, чтобы иметь подробные общедоступные идентификаторы и короткие частные.

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

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

Ответ 9

Также рассмотрите, где он будет использоваться, ClearScreen(), вероятно, появится сам по себе.
Однако вы сжимаете, когда новые программисты, которые узнали, что идентификатор должен быть легко читаемым, генерируют код типа.

 screenCoordinateVertical = gradientOfLine * screenCoordinateHoriontal + screenCoordinateOrigin;

вместо

 y = m*x + C;

Ответ 10

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

С учетом сказанного я согласен с предыдущими комментариями о балансе. Как и в случае с таким количеством ответов, "это зависит". Но я одобряю многословие и ясность. Вывод гласных для старых администраторов баз данных.

Ответ 11

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

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

Ответ 12

Всегда использование полных слов в идентификаторах также помогает поддерживать согласованность.

С аббревиатурами всегда возникает вопрос, было ли слово сокращено, и если да, то как.

Например, прямо сейчас я смотрю код, который имеет индекс сокращенно ndx или idx в разных местах.

Для очень локального контекста это нормально сокращать, но тогда я бы использовал только первую букву каждого слова, чтобы гарантировать согласованность. Например. sb для StringBuilder.

Ответ 13

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

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

Взглянув на код в социальном контексте, вы должны следовать соглашениям об именах, на которые ссылается:

• Проект
• Компания
• Язык программирования

.. в этом порядке.

Ответ 14

Это действительно все о том, чтобы найти баланс между ними, который достаточно прост для чтения, в то же время не слишком многословный. Многие люди испытывают личную неприязнь к Java или Win32, разрабатывают имена функций/классов, но многие другие также не любят очень короткие идентификаторы.

Ответ 15

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

Ответ 16

Ничего плохого в коротком идентификаторе до тех пор, пока его очевидное, что это значит.

Лично я склоняюсь к последнему, потому что я предпочитаю быть подробным (хотя я стараюсь не быть таким подробным, как MS и их функция CoMarshallInterthreadInterfaceInStream), но пока функция Clear Screen не называется "F()" я не вижу проблемы:)

Ответ 17

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

Нижняя строка всегда - пусть все имеет смысл (да, очень субъективно).
Поиск в Wikibook - Имена идентификаторов

Ответ 18

Также нужно подумать о , где идентификатор, хорошо известный я как счетчик итераций является допустимым примером:

for(int i=0;i<10;i++){
    doSomething();
}

Если контекст прост, идентификатор должен соответствующим образом отражать это.

Ответ 19

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