Шпаргалка по выбору хороших имен и отказу от плохих

Вы знаете хорошие и плохие имена функций, когда видите их в чужом коде, верно? Тогда почему так сложно придумать имена для вещей в нашем коде?? Мы тратим так много времени, глядя на этот мигающий курсор на экране, пока пытаемся придумать идеальное название для чего-то.

Возможно, причина того, что в нашем коде так сложно давать имена, заключается в том, что мы на самом деле не понимаем, что наш код будет делать, пока не напишем его. Я придумал несколько приемов, которые избавили меня от проблем с именами, и хочу поделиться ими с вами! Это может изменить вашу жизнь!

Резюме / TL; DR

  • Хорошие имена: сообщает, что делает вещь, и следует принципу единой ответственности (SRP). Как правило, здесь меньше значит больше.
  • Предупреждения о недопустимом имени: содержит несколько союзов (например, и, или, но, для и т. д.); читается как пользовательская история; не описывает, что делает вещь.
  • Секрет именования вещей: не тратьте время понапрасну. Назовите его как-нибудь произвольно (ThingOne, ServiceOne, userArray и т. д.) и начните писать код. Вернитесь и исправьте имя после того, как вы действительно узнаете, что будет делать код.

Что делает хорошее имя «хорошим»?

  • Значимый. Хорошее название говорит о том, что что-то делает. Это выражение ожиданий и предположений разработчика, связанных с конкретным фрагментом кода.
  • Не требует пояснений. Хорошие имена обычно не требуют специальных объяснений, кроме терминологии, характерной для бизнеса. Большинство хороших имен не нуждаются в комментариях, чтобы объяснить их.
  • Следуйте принципу единой ответственности (SRP). Каждый класс или метод должен отвечать за выполнение только одной работы, поэтому их название должно отражать эту единственную ответственность. Обычно вы получаете короткие имена, когда следуете SRP, хотя это НЕ обязательно означает, что длинное имя — плохое имя.

Хорошие имена также следуют установленным шаблонам. Вот некоторые примеры:

  • Имена функций Javascript и Typescript должны быть написаны в верблюжьем регистре (например, myFunctionName()).
  • методы, которые вызывают вызовы REST, должны использовать соответствующие глаголы REST (например, putUserPreferences(), getShippingAddress(), postTakeoutMenuUpdate())
  • Никаких сторонних имен (обычно). Что произойдет с вашим именем метода getMapQuestDirections(), если MapQuest больше не существует? Лучше называть его getDirections() или getDrivingDirections()

Плохие имена и как их исправить

Мое имя все время растет, и я живу очень-очень долго; поэтому мое имя похоже на историю. Настоящие имена рассказывают вам историю вещей, которым они принадлежат, на моем языке…
Две башни, Толкин

🚩 КРАСНЫЙ ФЛАГ: Формат «Дано-когда-тогда» или «Действовать-когда-если»
Звучит ли название как описание пользовательской истории?

sendMarketingEmailsWhenOrderShipsIfOptedIn()

Это плохое имя! В этом имени функции слишком много ненужных деталей.

Давайте исправим это!

Обрежьте детали и условный язык: sendMarketingEmails(). Храните детали выполнения внутри тела функции, а не в имени.

🚩 КРАСНЫЙ ФЛАГ: несколько союзов (и, для, но, или и т. д.)

Имя звучит как целое предложение?

checkUserCredentialsAndLogThemInIfAuthenticatedThenFetchPreferencesAndRouteToDashboardOrRouteToLoginIfNotAuthenticated()

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

Давайте исправим это!

Разделите его на отдельные обязанности: authenticateUser(), getPreferences(), route().

🚩 КРАСНЫЙ ФЛАГ: название не описывает код
Что, если вы столкнетесь с чем-то вроде этого:

Этот код на самом деле не удаляет адрес. Может быть, много лет назад, когда этот код был впервые написан, он использовал http-вызов и удалял адрес, но сейчас этого не происходит. Название неточное.

Давайте исправим это!

Переименуйте эту функцию, например, inactivateShippingAddress.

Шпаргалка по именам для всех!

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

2. Напишите свой код единой ответственности
Это то, во что вы в любом случае должны вкладывать свое время и умственные способности!

3. ⚠️⚠️⚠️️️Замените временное имя⚠️⚠️⚠️
После того, как вы будете удовлетворены написанным кодом, вернитесь и измените одноразовое имя . Если вы написали функцию, выполняющую только одну задачу, теперь вы будете точно знать, как назвать эту функцию!

Вот и все! Боль не нужна. Раньше я терял ОЧЕНЬ МНОГО ВРЕМЕНИ, пытаясь понять, как назвать свои службы и функции. Уже нет. Обычно я не знаю идеального имени, когда начинаю писать свой код, поэтому я просто добавляю whatever() или let tempyHama в свою IDE и продолжаю двигаться. Я говорю вам, это изменило мою жизнь как программиста. Я надеюсь, что это делает то же самое для вас.

О HeroDevs

HeroDevs — студия разработки программного обеспечения и консалтинга, специализирующаяся на разработке интерфейса. Наша команда является автором или соавтором таких проектов, как Angular CLI, Angular Universal, Scully, XLTS — расширенная долгосрочная поддержка AngularJS, Ng-conf и многих других. Мы работаем с быстрорастущими стартапами и крупнейшими мировыми компаниями, такими как Google, GE, Capital One, Experian, T-Mobile, Corteva и другими. Узнайте больше о нас на herodevs.com