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

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

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

Если контекст простой, идентификатор должен отразите это соответственно.

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

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

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

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

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

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

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

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

1. Проектом
2. Компанией
3. Языком программирования

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

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

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

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

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

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

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

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

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

 screenCoordinateVertical = gradientOfLine * screenCoordinateHoriontal + screenCoordinateOrigin;

вместо

 y = m*x + C;

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

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

Лично я предпочитаю иметь подробные общедоступные идентификаторы и короткие частные.

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

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

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

ClearScreenBeforeRerenderingPage ()

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

Clear_Screen_Before_Rerendering_Page ()

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

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

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

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

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

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

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

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

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

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

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

ClearScreen() 

, на мой взгляд, легче разбирать, чем

clrscr() 

, но

ClearScreenBeforeRerenderingPage() 

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

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

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