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

Question

Я всегда задавался вопросом: существуют ли какие-либо неопровержимые факты, которые указывали бы на то, что более короткие или более длинные идентификаторы лучше?

Пример:

clrscr()

против

ClearScreen()

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

Существуют ли другие аспекты, которые предлагают короткий или подробный стиль?

РЕДАКТИРОВАТЬ: Просто чтобы уточнить: я не спрашивал: «Что бы вы сделали в этом случае?». Я спросил о причинах, чтобы предпочесть одно другому, то есть это не вопрос опроса.

Пожалуйста, , если можете, укажите причину , почему один предпочитает один стиль другому.

Answer 1

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

ClearScreen() 

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

clrscr() 

на мой взгляд, но

ClearScreenBeforeRerenderingPage() 

это просто шум.

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

Лично мне нравится пытаться следовать мудрости Чистый код от дяди Боба.

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

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

Answer 5

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

ClearScreenBeforeRerenderingPage()

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

Clear_Screen_Before_Rerendering_Page()

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

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

Answer 6

Пожалуйста, перейдите непосредственно к соответствующей главе «Выполнение кода» Стива Макконнелла ( продезинфицированная ссылка Amazon ).

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

Answer 7

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

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

Answer 8

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

 screenCoordinateVertical = gradientOfLine * screenCoordinateHoriontal + screenCoordinateOrigin;

вместо

 y = m*x + C;

Answer 9

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

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

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

Answer 10

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

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

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

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