Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

1 Ниже представлена подборка типичных ошибок, которые допускают программисты при именовании переменных и функций в своём коде. Примеры взяты из проектов учеников Хекслета. В качестве языка для демонстрации я использую JavaScript, как наиболее универсальный, но сами примеры никак не связаны с тем, какой язык используется. Эти ошибки встречаются везде в одинаковых пропорциях.

2 Материалы, на которых базируются принципы именования:

3 <ul><li><a>Правильное именование переменных</a></li>

4 <li><a>Ментальное программирование</a></li>

5 <li><a>Ментальное программирование II</a></li>

6 <li><a>Ментальное программирование III</a></li>

7 </ul><blockquote>Подписывайтесь на<a>канал Кирилла Мокевнина в Telegram</a>- чтобы узнать больше о программировании и профессиональном пути разработчика

8 </blockquote>Коротко о смыслах.

9 Идеально, если одного имени достаточно для понимания того, что находится внутри переменной иличтоделает функция, а некакона это делает. Если для понимания нужно изучать код вокруг этого имени, то, скорее всего, имя плохое. Основная мысль: Не заставляйте меня (человека, читающего ваш код) думать!

10 <h3>Файл?</h3>

11 Моё "любимое" имя для переменной -file. Особенно прекрасно, когда не видно момента присваивания - например, при передаче этого "файла" в функцию:

12 Что такое файл? Если задать этот вопрос разным людям, то получим разные ответы. Типичный список такой:

13 <ul><li>Содержимое файла</li>

14 <li>Имя файла</li>

15 <li>Путь до файла</li>

16 <li>Файловый дескриптор</li>

17 </ul>На практике встречаются все эти варианты. Правда, последний всё же больше относится к языкам типа СИ, где под файлом действительно имеют в виду файловый дескриптор.

18 Имяfile- плохое, оно заставляет проводить в голове трансляцию из имени в его реальную суть: "говорим файл, подразумеваем путь" или "говорим файл, подразумеваем содержимое". Правильные имена:filepath,filename,content.

19 <h3>Венгерская нотация</h3>

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

21 <ul><li>Массивы. Если что-то массив, то, значит, у нас есть коллекция каких-то элементов, а у элементов есть имена. Идеальное имя для такого массива - это имя элемента во множественном числе:users,cars,numbersили, на крайний случай,items. Все они явно говорят о том, что мы работаем с коллекцией.</li>

22 <li>Строки. Здесь всё просто: если мы работаем с произвольной строкой, то её можно назватьtextилиsentence. В более конкретных случаях это может бытьcharилиword.</li>

23 <li>Числа. Тут ещё проще:number- он и в Африкеnumber. Но, конечно, лучше давать имя, соответствующее предназначению числа: например,denom(делитель).</li>

24 </ul><h3>Общие названия</h3>

25 В проектах часто можно встретить названия в стилеbeforeилиafter(встречается вариацияnewиold). Хочется сразу спросить"Что до?"и"Что после?". Абсолютно непонятно, о чём идёт речь, не зная кода. Конкретно в тех ситуациях, о которых я говорю, имелось ввиду значение до изменений и значение после изменений. Собственно, весь секрет - именовать переменные так, чтобы они отражали эту суть:valueBeforeиvalueAfter.

26 Такая же история с функциями. Как вы думаете, что происходит в коде ниже?

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

28 <h3>Функция - существительное</h3>

29 Именование функций существительными - частый антипаттерн даже у опытных разработчиков. Ниже примеры, где слева - то, как пишут, справа - то, как должно быть в соответствии со смыслом:

30 <ul><li>diff(value) => genDiff(value)</li>

31 <li>parser(data) => parse(data)</li>

32 <li>value(user) => getValue(user)</li>

33 </ul>В программировании используется не такой большой набор слов, которые означают различные действия и используются при этом очень часто. К таким словам относятся модальные глаголы и слова типаrender,build,generate,show,enable,set,get,editи другие.

34 Сюда же можно отнести путаницу с порядком слов. Иногда встречаются подобные варианты:diffBuild, но правильно писать наоборот:buildDiff. Сначала "что делаем?" (какое действие), затем "над чем?" (предмет, на который направлено действие).

35 <h3>Сокращения</h3>

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

37 <ul><li>empt(сокращение отempty)</li>

38 <li>hid(сокращение отhide)</li>

39 </ul>Такое сокращение не просто не делает лучше - оно делает только хуже, так как полное слово внезапно становится неочевидным, да и прочитать такое имя бывает проблематично. Зачем сокращать на одну букву, мне не понятно, но делать так точно не стоит.

40 А вот длинные имена обычно оказываются хорошим выбором. Не надо их бояться. Например, в Rails есть функции со следующими названиями:distance_of_time_in_wordsилиoption_groups_from_collection_for_select.

41 <h3>Парные не парные</h3>

42 В программировании часто встречаются ситуации, для которых идеально подходят антонимы - слова, имеющие противоположный смысл. Например: начало-конец, новый-старый, до-после. И в таких ситуациях нужно уметь правильно подбирать эти слова. Например, какой антоним к словуbegin? Правильный ответ:end, а неfinish(антоним дляstart), как думают многие.

43 Я часто наблюдаю ситуацию, когда в коде только одно слово делают правильным, а второе остаётся нейтральным. Типичный пример: у нас есть старое значение и новое значение. Программист создаёт паруvalueиnewValue. Но это неправильно. Проблема в том, что из этой пары не очевидна связь. Более того, нужно ещё умудриться догадаться, что подvalueподразумеваетсяoldValue. А как мы помним, имя должно сразу говорить о своём смысле без необходимости додумывать.

44 <h3>Транслитерация</h3>

45 Самый короткий пункт. Имена в стилеchisloилиnodaговорят о том, что автор этого кода не умеет и не хочет пользоваться переводчиком.

46 Расскажите в комментариях о своём опыте. Какие имена переменных вы встречали?

47 <blockquote><h3>Дополнительные материалы</h3>

48 <ul><li><a>Именование в программировании</a></li>

49 </ul></blockquote>