До 30 ноября

Скидки до 81 000 руб и вторая профессия в подарок!

Главная | Все статьи | Код

Совершенный код: ошибки именования в программировании I

Время чтения статьи ~5 минут 295
Совершенный код: ошибки именования в программировании I главное изображение

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

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

Подписывайтесь на канал Кирилла Мокевнина в Telegram — чтобы узнать больше о программировании и профессиональном пути разработчика

Коротко о смыслах.

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

Файл?

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

const f = (file) => {
  // что-то делаем с «файлом»
};

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

  • Содержимое файла
  • Имя файла
  • Путь до файла
  • Файловый дескриптор

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

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

Венгерская нотация

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

  • Массивы. Если что-то массив, то, значит, у нас есть коллекция каких-то элементов, а у элементов есть имена. Идеальное имя для такого массива — это имя элемента во множественном числе: users, cars, numbers или, на крайний случай, items. Все они явно говорят о том, что мы работаем с коллекцией.
  • Строки. Здесь всё просто: если мы работаем с произвольной строкой, то её можно назвать text или sentence. В более конкретных случаях это может быть char или word.
  • Числа. Тут ещё проще: number — он и в Африке number. Но, конечно, лучше давать имя, соответствующее предназначению числа: например, denom (делитель).

Общие названия

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

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

process(data);

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

getName(user);

Функция — существительное

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

  • diff(value) => genDiff(value)
  • parser(data) => parse(data)
  • value(user) => getValue(user)

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

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

Сокращения

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

  • empt (сокращение от empty)
  • hid (сокращение от hide)

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

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

Парные не парные

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

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

Транслитерация

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

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

Дополнительные материалы

Аватар пользователя Kirill Mokevnin
Kirill Mokevnin 02 января 2019
295
Рекомендуемые программы
профессия
Осваивайте разработку веб-страниц, оживляйте дизайн макетов, публикуйте сайты и приложения. Отслеживайте ошибки в интерфейсе и устраняйте их
10 месяцев
с нуля
Старт 21 ноября
профессия
Обучитесь разработке бэкенда сайтов и веб-приложений — серверной части, которая отвечает за логику и базы данных
10 месяцев
с нуля
Старт 21 ноября
профессия
Выполняйте ручное тестирование веб-приложений, находите ошибки в продукте. Узнайте все о тест-дизайне.
4 месяца
с нуля
Старт 21 ноября
профессия
Научитесь разработке веб-приложений, сайтов и программного обеспечения на языке Java, программируйте и используйте структуры данных
10 месяцев
с нуля
Старт 21 ноября
профессия
новый
Собирайте, анализируйте и интерпретируйте данные, улучшайте бизнес-процессы и продукт компании. Обучитесь работе с библиотеками Python
9 месяцев
с нуля
Старт 21 ноября
профессия
Занимайтесь созданием сайтов, веб-приложений, сервисов и их интеграцией с внутренними бизнес-системами на бекенд-языке PHP
10 месяцев
с нуля
Старт 21 ноября
профессия
Создание веб-приложений со скоростью света
5 месяцев
c опытом
Старт 21 ноября
профессия
Обучитесь разработке визуальной части сайта — фронтенда, а также реализации серверной — бэкенда. Освойте HTML, CSS, JavaScript
16 месяцев
с нуля
Старт 21 ноября
профессия
Разработка бэкенд-компонентов для веб-приложений
10 месяцев
с нуля
Старт 21 ноября
профессия
новый
Организовывайте процесс автоматизации тестирования на проекте, обучитесь языку программирования JavaScript, начните управлять процессом тестирования
8 месяцев
c опытом
Старт 21 ноября