Проблема выбора подходящего имени для переменной распространена повсеместно. Об этом можно судить по количеству созданных мемов:
Есть разные стили для задания имён переменных, например snake_case или camelCase. Но здесь речь не про них, а про выбор самих имён.
1. Национальные особенности
Правилом хорошего тона является именовать всё по-английски. Это универсальный язык программистов. В интернациональных проектах по-другому и быть не может.
Но зачастую можно встретить код, написанный в одиночку немцем или испанцем, с наименованиями на его родном языке. Что ж, это его полное право. В то же время русские программисты, пытаясь создать русские наименования переменных, сталкиваются с фундаментальной проблемой – транслитом. Если немецкое или испанское слово легко записать латинским алфавитом, русские слова очень плохо поддаются латинизации и к тому же часто оказываются слишком длинными. Например, DEJSTVUYUSCHIY_TARIF. Во многих языках программирования переменные можно писать прямо в родном алфавите, но и это вызывает сложности – приходится постоянно переключать язык на клавиатуре, да и в целом такой программный код раздражает.
2. Опечатки, лень и безграмотность
Очень многие (и это просто катастрофа) переменные называются с ошибками. Если ошибка не сделана сразу, то её можно сделать потом, а услужливый "интеллектуальный" IDE размножит её повсюду, где упоминается эта переменная.
Поэтому в одном и том же коде, на двух соседних строчках, можно встретить названия Analyze и Analize, или CANCELED и CANCELLED и очевидно, писавшему их было похрен абсолютно на всё. Зачем читать то, что пишешь, если IDE подставит всё за тебя?
Отдельная расстрельная статья это слово separate, которое многие даже носители языка пишут как seperate.
Есть необъяснимое свойство у слова ratio. Всякий раз, когда вы будете его печатать, у вас будет получаться ration.
3. Незнание контекста
Если программист знает английский на начальном уровне, он сможет писать слова вроде user, list, и т.д. Но когда дело доходит до нестандартных случаев, он либо напишет то, что когда-то слышал, либо посмотрит в словарь. И как правило выберет неподходящее слово. Скажем, мы знаем, что кухня это kitchen. И когда делается, скажем, кулинарный сайт про кухни разных стран, то программист может сходу использовать слово kitchen и будет неправ. Потому что kitchen это помещение, где готовят, а нужно cuisine.
4. Зарезервированные слова
Некоторые переменные несут очень простой смысл – user, name, list, for, in, out – но назвать их именно так бывает нельзя. Потому что это зарезервированные слова в самом языке программирования или где-то ещё.
Если переменную нельзя назвать name, то как? Это настолько просто, что других вариантов и нет. Глупая ситуация, правда?
Что делать?
Я поделюсь тем, как решаю эти проблемы. Эти решения не имеют под собой никаких серьёзных обоснований, поэтому я не говорю, что это правильно или нет.
В затруднительной ситуации мне важно, чтобы было комфортно именно мне – ведь это я пишу код, и имею на это право.
Комфорт важен, чтобы не спотыкаться и не раздражаться каждый раз.
Как его добиться – уже дело личных предпочтений. Например, я знаю человека, который локальные и временные переменные без раздумий называл govno или jopa. Всегда.
Для меня комфортно, во-первых, не видеть постоянно мозолящих глаз орфографических ошибок и разных вариантов написания одного и того же слова, потому что писавший его был не в состоянии повторить два раза одинаково.
Поэтому я даже в чужом коде сначала потрачу время на рефакторинг имён, и только потом начну работать над кодом.
Когда имя переменной выходит чересчур корявым, я заменяю его на что-то более неформальное и желательно юмористичное. Например вот тут:
Я уже был порядком измучен, а переменную для длины остатка последовательности нужно было назвать типа sequence_numbers_left. Это меня не устроило и я назвал её просто bingo. Когда она обнуляется, то происходит "выигрыш в бинго", что по смыслу совпадает с задачей. Настроение сразу улучшилось.
Когда было недоступно название name, я заменил его на японский вариант – namae. И понятно, и конфликтов не вызывает. С тех пор часто пользуюсь. Так я понял, что многим словам можно подыскать эквиваленты из других языков, которые всё равно останутся понятны в силу культурного кода. Например, если написать muchacho, то несмотря на испанское происхождение, мы знаем о чём речь. Плюс это будет весело.
Однажды я видел кусок кода словенского программиста. Он описывал некую RPG и выглядел очень уютно. Там что-то было про игрока, который ходит по лесу и выходит на обрыв над побережьем, и каждая сущность внутри программы называлась своим особенным словом, из которых я сейчас помню только oseba. Отличное ламповое слово, хорошо пишется и звучит. А потом до меня дошло, что oseba это "особа", то есть в данном случае персонаж игры, который мог бы называться player или person.
Код, написанный с разумным использованием таких этнически родных слов, имеет некое очарование, и мне кажется, это очень важно, когда вы пишете какой-то свой проект, находиться с ним на одной волне.
