Кратко о нейминге в JS -4



Привет, Хабр! Решил затронуть тему наименования сущностей в Javascript. По работе довольно много взаимодействую со стажёрами и насмотрелся всякого. Вот и подумал, что было бы неплохо собрать в одной небольшой заметке принятые на сегодняшний день правила наименования сущностей в JavaScript сообществе. Возможно собрал не все, поэтому буду признателен если дополните меня в комментариях.

Именование сущностей


Именование очень важно в разработке ПО. Как мы знаем, код пишется в первую очередь для людей, которые будут его читать(для программистов). Неудачное именование может существенно повысить трудозатраты на разработку или поддержку проекта из-за того, что будет тратится лишнее время на чтение кода, т.к. при плохом нейминге затруднён процесс интерпретации «что есть что в коде».

Существуют разные синтаксические формы наименования, их очень много, некоторые уже не употребляются. Вот самые употребимые в js:

  • Верблюжья нотация (CamelCase): MyClass
  • Змеиная нотация (snake_case): my_const
  • Шашлычная нотация (kebab-case): my-data

При выборе кейса важно учитывать принятый на текущий момент стандарт. В js на сегодняшний день snake_case и kebab-case не приняты, но их можно встретить например на Python или Ruby.

Однобуквенные идентификаторы


В институтах очень часто используют однбуквенные идентификаторы в коде. Я вижу этот стиль кодирования у половины ребят, которые приходят после ВУЗов. Это очень порочная практика. Название должно наглядно описывать сущность. В наше время использовать однобуквенные идентификаторы — признак дурного тона. Исключениями могут быть счётчики и индексы, т.е. ситуации, где и одной буквы более чем достаточно для передачи сути сущности.

Транслит в имени


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

Именование переменных и классов


Переменные именуются в lower camelCase:

const maxCount = 10;

Классы именуются в CamelCase:

class EnumerableCollection {
//some code
}

Действия


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

const checkNumberIsEven = (number) => (number % 2 === 0);

checkNumberIsEven — хорошее название. сразу понятно, что функция проверяет число на чётность.

Также хорошее название isEven — если эта функция лежит в каком — нибудь /helpers/number.js, то даже такого короткого названия более чем достаточно, т.к. сама директория указывает нам на то, что в неё лежат функции по работе с числами.(но даже тут можно использовать первый вариант, т.к. в файле, который использует данную функцию, может быт довольно много кода, а вызов быть где нибудь в середине. )

Функции далеко не всегда являются действиями, это тоже важно понимать.
Например,

const arifmeticalProgression = (start, depth, maxLength = 10) => {
  const progression = [start];
  const iter = (acc) => {
    if (acc.length >= maxLength) {
      return acc;
    }
    const newIndex = acc.length;
    const newItem = start + newIndex * depth;
    const newProgresion = [].concat(acc, newItem);
    return iter(newProgresion);
  };
  return iter(progression);
};

Эта функция генерирует нам арифметическую прогрессию, но действием не является, т.к. в виду своей декларативности считается определение арифметической прогрессии. Важно уметь различать этот момент. Сюда же относятся функции определяющие константы.

const defaultCollection = () => ([]);

Предикаты


Выше мы обсуждали функцию

const checkNumberIsEven = (number) => (number % 2 === 0);

Такой тип функций называют предикатами. Предикат — утверждение о чём либо. Так называют функции выполняющиеся проверки «сущность есть что-то». Предикат в программирование всегда возвращает булевое значение.

Как правило предикаты именуются через форму третьего лица единственого числа английского вспомогательного глагола to be, т.е. is.

const isEven = (number) => (number % 2 === 0);

Некоторые предикаты определяют вхождение(наличие) искомого элемента(свойства или метода или item'a) в сущности. Такие предикаты. как правило начинаются с английского глагола has(3е лицо единственное число глагола to have). Например, безопасная форма Object.prototype.hasOwnProperty может выглядеть так:

const hasProp = (obj, key) => (Object.prototype.hasOwnProperty.call(obj, key));

Если сущность представляет собой количество чего-либо, то стоит использовать слово count в названии.

Теги:




Комментарии (29):

  1. vivcogit
    /#21276808

    Вот самые употребимые в js:

    Шашлычная нотация (kebab-case): my-data

    Тут падает желание читать дальше т.к. таких именований в JS быть не может (как и во многих других языках программирования), поскольку это будет расцениваться как: my(минус)data.

    Также дальше идет предложение
    В js на сегодняшний день snake_case и kebab-case не приняты

    Которое противоречит «самые употребимые» из предыдущего

    • Carduelis
      /#21277850

      Между прочим, все верно описано. Может быть сумбурно, но верно.


      В век до es6 очень часто в js писали имена атрибутов через дефис. data-id, data-name.
      И кебаб-кейс еще присутствовал в css.


      А вот с приходом фреймворков типа React, кебаб-кейс уже перестал быть важным. Никому не нужны data-attributes. Да и CSS-in-JS стал популярным, заменив background-color на backgroundColor.


      О времена, о нравы!

      • vivcogit
        /#21278362

        имена атрибутов — до сих пор используются, и в кебаб-кейсе, не спорю. CSS свойства тоже в кебабе. Это стандартами задано и нет смысла обсуждать, да и css все таки хоть и тесно связан с браузерным js, но не часть его. И если я правильно понял статью, то она в первую очередь про именования переменных/классов/функций, в общем сущностей из кода.

        • Alex_Shcherbackov
          /#21284300

          Также эти кейсы можно встретить в легаси коде и много где ещё. Всё так критика должна бать обоснованной. Фраза вырванная из контекста не отражает суть повествования.

          • kahi4
            /#21286568

            Покажите нам примеры легаси кода с кебаб-кейсом, пожалуйста.


            Это невалидный синтаксис в js, так что это автоматически не может быть плохим стилем, но в это же время и спецификация того же css, вы обязаны это использовать, и, поэтому, это не опять не может быть плохим тоном.

      • justhabrauser
        /#21279478

        kebab-case… можно встретить… на Python

        И где тут всё верно?
        За такое сразу садисьдва надо.

    • Alex_Shcherbackov
      /#21284176

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

      Извините, но если вы не дочитали, то это только ваш выбор.

  2. demsee
    /#21276842

    А нельзя ли подробней рассказать про стандарты неймига для различных языков. Например, применима ли шашлычная нотация для всех LISP-подобных языков? Какая нотация применима для С, С++, C#?

    • Alexey_Alive
      /#21282592

      В Си используются разные нотации в разных либах. Например, Microsoft, используют UpperCamelCase (CreateProcessA). В Unix используют либо camel case (set_mempolicy), либо чаще хрен пойми что (chmod, shmctl), при этом почти все слова сокращая и не используя заглавных букв.

    • Alex_Shcherbackov
      /#21284184

      Увы, я не смогу компетентно рассказать про С, С++, C#.

  3. GennPen
    /#21277020

    При выборе кейса важно учитывать принятый на текущий момент стандарт. В js на сегодняшний день snake_case и kebab-case не приняты, но их можно встретить например на Python или Ruby.
    Нейминг не имеет стандарта как такового. Все что описано в статье — это рекомендации, а не стандарт. Каждый решает для себя как именовать, придерживаться или нет рекомендаций. В корпоративной разработке могут быть свои правила именования, от которых обычно нельзя отклоняться.

    • Alex_Shcherbackov
      /#21284188

      Поэтому я и написал, что важно учитывать принятый на текущий момент стандарт.

  4. kAIST
    /#21277888

    О, а как мне в python'e обозвать переменную some-var?
    На ус приходит только что нибудь эдакое из юникода, но это клиника.

  5. baxxter
    /#21279274

    Функции далеко не всегда являются действиями

    Не соглашусь. Результат выполнения функций — не всегда действие, а сама функция всегда выполняет какое то действие, вернуть что либо — это тоже действие.
    Такой нейминг примеров из статьи на мой взгляд более удачный:
    defaultCollection > getDefaultCollection
    arifmeticalProgression > getArifmeticalProgression


    Глагол явно указывает на то, что в переменной функция и её можно вызвать

    • VolCh
      /#21279678

      А для, например, синуса вы пишите свои обёртки типа getSinus? А для ФВП, возвращающих другие функции пишете getGetSomething?


      Лично я в большинстве случаев против имён обычных функций с префиксами get, calc, do, transform, и т. п. — считаю их лёгким запашком по умолчанию.

      • baxxter
        /#21279764

        Если говорить про частично примененный синус от какого то стейта, то почему бы и не написать getSinOfExecutionTime, не понимаю на чем экономить. Для ФВП есть вполне устоявшееся withSomething. Я говорил в контексте прикладного программирования, а не системного, где возможно разумно использовать другие рассуждения — тут не берусь судить конечно

        • VolCh
          /#21282920

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


          А withSomething это схема для декораторов обычно.

    • Alex_Shcherbackov
      /#21284196

      Тут речь о семантике кода. С точки зрения семантики функции могут выполнять некое действие(преобразование, отправку, изменение), а могут что-то возвращать(число, булево значение). И эти две разные ситуации именуются по разному.

  6. silentiumnoxe
    /#21284200

    Я бы не относил данные стандарты только к JS. Так как в Яве, плюсах, го и ещё пакет других языков тоже используются подобная практика.

  7. Artem27091997
    /#21284206

    На самом Деле с опытом это как то интуитивно выходит. Не зацикливался на этом никогда, но щас пробежался по коду (чисто стало интересно всему ли я следую) и все по канонам)
    Но для новичков мб правда полезная инфа

  8. ralyeh
    /#21284208 / +1

    Мне известны:

    • camelCase — первое слово начинается со строчной буквы, каждое следующее слово с заглавной буквы, слова пишутся слитно;
    • PascalCase — каждое слово начинается с заглавной буквы, слова пишутся слитно;
    • kebab-case — все буквы строчные, слова отделяются символом "-";
    • snake_case — все буквы строчные, слова отделяются символом "_";
    • UPPER_CASE_SNAKE_CASE — все буквы заглавные, слова отделяются символом "_".

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

    Про lower camelCase слышу впервые. Можно ссылку на источник?

    Не согласен с утверждением «Функции далеко не всегда являются действиями», поскольку в примере приводится пример чего-то похожего на ленивые генераторы и конструктор типа, которые обычно именуются в форме глагола. Не сталкивался с хорошим обоснованием именовать функции в форме существутельных. Пример с созданием коллекции по умолчанию в js выглядит как вредный совет, поскольку при каждом вызове такой функции будет каждый раз создаваться новый объект.

    • Alex_Shcherbackov
      /#21284214

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

      На тему lower camelCase. upper CamelCase это тотже PascalCase.

  9. Oleg_Filonchuk
    /#21284216

    Интересно было бы посмотреть на именование переменных в кебаб-кейсе в JS.

    • Alex_Shcherbackov
      /#21284222

      Я привёл самые употребимые в программировании на 2020, а потом рассказал, что сейчас принято в js.

  10. Alex_Shcherbackov
    /#21284226

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