Вопросы наименования
Правильное название кода может сэкономить вам и вашим коллегам много времени. вот как…
Будь то переменные или функции, именование играет важную роль в отладке и понимании кода, и, поскольку мы тратим больше времени на чтение кода, чем на его написание, важно, чтобы мы обращали внимание на этот (несколько игнорируемый) аспект кодирования.
Ценность правильного именования кода настолько очевидна в каждый час, который я трачу на чтение кода, и в этом посте я хотел бы поделиться с вами своими практиками и практическими правилами именования кода.
Переменные
Вообще говоря…
Все создают переменные, но очень немногие находят время, чтобы действительно правильно назвать их. Причины этого могут быть разными, но в основном это потому, что мы хотели проверить, что что-то работает очень быстро, и оставили там переменную «t», чтобы озадачить будущих сопровождающих (обычно самих себя).
Мое практическое правило по этому поводу -
Имя переменной должно максимально точно указывать ее значение
и это не означает, к какому типу относится переменная. Меня не волнует, число это или строка. Однако меня волнует, представляет ли он количество элементов или имя пользователя.
Вы можете подумать, что приведенное выше тривиально, но держу пари, что вы можете найти много мест в поддерживаемом вами коде, где переменная вводила в заблуждение и заставляла вас сбиться с пути логически.
Вы будете читать это имя переменной много раз, так что вы могли бы также установить его, чтобы помочь вам. Если мы углубимся немного глубже, я следую правилам, которые относятся к типу переменной:
Булевы
Правило здесь для меня довольно простое и понятное -
Логические переменные представляют собой вопрос типа да / нет. Я спрошу: "Это вид в быстром режиме?" или "есть ли у этого объекта предметы?"
И это создаст прямые имена переменных, такие как «isInFastMode» в области просмотра или «hasItems »В области видимости объекта. Я считаю альтернативу «fastMode» и «items» плохой практикой и вводящей в заблуждение. Я бы предпочел, чтобы мои условные выражения читались как можно ближе к простому английскому, например if (isInFastMode), чем разработчики закрутили английский синтаксис if (fastMode).
Коллекция vs. одиночный
Иногда у вас есть коллекция, скажем «элементы», и внутри этой коллекции каждый объект представляет собой отдельный «элемент». Если мы возьмем их такими, какие они есть, и будем использовать их для имен переменных, мы столкнемся с проблемой. Проблема в двух разных переменных, которые можно отличить только по одной маленькой букве «s» в конце их имени. Это, друзья мои, основная причина многих часов отладки, которые заканчиваются «черт возьми! есть там! ».
Чтобы избежать этого, я установил правило -
Имея дело с коллекциями, я использую множественное число, например «items», но когда имею дело с одним элементом, я называю его «singleItem».
Это действительно помогает мне сразу сказать, что есть что. Опять же, это может показаться вам мелочным, но помимо оптимизации производительности вашего кода вам также следует позаботиться об оптимизации скорости чтения кода, и это именно то, что вам нужно.
Функции
Вообще говоря…
Функции - это ключевой аспект языка, которым я сейчас занимаюсь, то есть JavaScript, и это требует от меня особого уважения к их названию.
Как и в случае с переменными, имена функций должны указывать на то, что функция делает, поэтому мое первое правило -
Если трудно найти имя, которое определяет, что делает ваша функция, это обычно означает, что ваша функция делает слишком много и ее необходимо разбить на более мелкие функции (функция извлечения).
Это и то
Иногда имя, которое вы инстинктивно даете функции, может предупредить вас о том, что ваш дизайн немного «пахнет».
Если в имени вашей функции есть «и», например «SeekAndDistroy ()», в большинстве случаев это означает, что эта функция выполняет 2 действия.
И поэтому должен быть извлечен в 2 разные функции, например seek () и destroy () и вызывать их один за другим или, что еще лучше, получить гибкость для вызова одного из них без другого.
Функции геттеров
В отличие от метода получения объекта JavaScript, этот относится к функциям, которые возвращают значение в соответствии с одним или двумя аргументами. Их имя, очевидно, должно указывать на их цель, поэтому глагол «получить» должен находиться там, например «получить ItemById (id)».
Функция, имя которой содержит «get», всегда должна возвращать какое-то вычисленное значение.
Я стараюсь избегать альтернативных глаголов, таких как «получить», «получить», «получить» и т. Д., Когда они не нужны, просто для того, чтобы мой код был согласован и облегчил жизнь тому, кто его читает.
Файлы
Вообще говоря…
Имена файлов очень помогают указать, что определено в этом файле. Учитывая, что вы не определяете несколько модулей внутри одного файла, знание имени файла может дать вам хорошее представление о его содержимом.
Так что об этом немногое -
Если файл определяет представление, я укажу его в его имени, например «Items-list-view.js»
Некоторые могут не согласиться с таким подходом, но я нашел его очень удобным для последующих поисков.
Тестовые файлы
Хотя тестовые файлы не привязаны к тестируемому коду, я стараюсь выровнять их по именам. Так что, если, например, у меня есть файлы «items-list-view.js», которые определяют… (ну, вы можете сказать, что он определяет, верно;), тогда соответствующий тестовый файл будет «items-list-view-spec.js» ». Это создает пары файлов, один из которых является источником, а другой - тестом. Результат - быстрый способ узнать, есть ли у определенного модуля тесты или нет.
вывод
Есть и другие примеры, которые я, вероятно, забыл, но хочу отметить, что уделять внимание тому, как мы называем ключевые аспекты нашего кода, стоит потраченных усилий. Присвоение подходящих имен, которые четко определяют назначение переменной, функции или чего-то еще, вы можете сэкономить много времени позже, будь то отладка или поддержка.
Если вам понравилось это читать, нажмите ♥ ниже. Это поможет поделиться историей с другими :)
