Раскройте смысл кода с помощью понятных имен

Введение

Это часть моего личного отчета о прочтении книги «Чистый код».

Прежде чем приступить к главе 2, давайте спросим себя

Что для вас значат осмысленные имена?

  • Относятся ли осмысленные имена к чему-то ясному и прямолинейному?
  • Относятся ли осмысленные имена к чему-то, что не вызывает у вас в голове вопросительного знака после прочтения?

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

  1. Раскрыть намерение
  2. Избегайте мысленного картирования
  3. Используйте существительное для имени класса, а имя метода должно иметь глагол
  4. Одно слово на понятие

Раскрыть намерение

Значимое имя должно раскрывать намерение. В этом разделе я предоставлю 3 разных сценария именования переменных,

  • Плохое имя переменной
  • Плохое имя переменной с описательным комментарием
  • Хорошее и ясное наименование переменных
  • Произносимое имя

Начнем с именования переменных.

Плохое имя переменной

const d = 24 * 60 * 60;

Из приведенного выше кода мы в принципе понятия не имеем, что для нас означает d? Даже автор кода может даже забыть об этом через некоторое время. Мы знали, что результат равен 24 * 60 * 60. Но мы точно не знаем, что он собой представляет. Поэтому мы не можем повторно использовать и поддерживать его.

Плохое имя переменной с описательным комментарием

Тем не менее, некоторые могут сказать, что мы можем просто добавить комментарий к коду, и это поможет устранить недопонимание, как в приведенном ниже коде.

const d = 24 * 60 * 60; // Day in seconds

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

Хорошее и ясное наименование переменных

Самый идеальный подход — использовать правильное имя переменной, раскрывающее назначение переменной. В этом случае переменная называется dayInSeconds..

Это просто, и я мог легко понять, что dayInSeconds делает с первого взгляда.

const dayInSeconds = 24 * 60 * 60;

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

getTransactions определенно здесь более ясно и прямолинейно, в то время как getData оставило у вас полную комнату для воображения, такую ​​как What kind of data?

Произносимое имя

Как правило, произносимое имя легко раскрывает намерение. Если вы не можете его произнести, вы вряд ли сможете обсудить его с коллегой. Поэтому произносимое имя всегда лучше передает намерение.

Избегайте ментального картирования

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

Наихудшие имена переменных, приведенные в книге, — это однобуквенные имена переменных, такие как a и b. В основном мы используем это в цикле for. Обычно это все еще работает в цикле for, если логика остается простой. Тем не менее, имя переменной, состоящее из одной буквы, в большинстве случаев является худшим выбором.

Это одна из замечательных цитат из книги.

Разница между умным программистом и профессиональным программистом заключается в том, что профессионал понимает, что главное — ясность. Профессионалы используют свои силы на благо и пишут код, понятный другим. — Чистый код, глава 2

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

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

Используйте существительное для имени класса, а имя метода должно иметь глагол

Мы должны использовать noun для имени класса, такого как Customer, Product и Transaction. Хотя в именах методов должны быть глаголы, такие как updateAddress. В приведенном ниже простом примере показано, как мы должны написать имя нашего класса и имя метода.

class Customerclass Customer {
  // Verb "update" in function name
  updateName(firstName, lastName)
}

Одно слово на концепцию

Использование одного слова для каждой концепции здесь имеет решающее значение. Попробуйте представить, если у вас есть 2 компонента с похожей ролью. Однако первый компонент называется UserController, а другой — TransactionManager.

Если вы новый член команды, вы в замешательстве. Теперь вы столкнулись с дилеммой и начинаете задавать себе вопросы:

  • В чем разница между Controller и Manager?
  • Почему у них разные имена концепций, когда они играют одну и ту же роль в кодовой базе?
  • Хуже всего то, что вы подумали, что это может быть какая-то новая концепция программирования, и попытались потратить свое время и поискать их в Google. «Контролер против менеджера».

Так что не путайте себя и других. Просто выберите по 1 слову для каждой концепции и всегда придерживайтесь их.

Заключение

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

Однако осмысленные имена не даются легко. Иногда для этого требовалось время и несколько рефакторингов. Так что не торопитесь в процессе.

Простой действенный шаг

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

Уведомление

Этот пост является частью резюме чтения, которое я написал в Gitbook. Вы можете прочитать Gitbook здесь.



GitBook
GitBookapp.gitbook.com



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

Надеюсь, вам понравится и спасибо за чтение.