Общепринятые соглашения при написании кода JavaScript

Нижнее подчеркивание перед именем свойства

Если переменная или метод имеют префикс "_", то это соглашение об именовании, которое напоминает разработчику о том, что переменная (свойство) или метод являются либо private, либо protected, и к ним нельзя получить доступ из-за пределов класса.

Делая объект Female равным не функции, а возвращаемому объекту, мы можем создавать private-переменные. Опять же, нижнее подчеркивание напоминает нам об этом.

Именование констант в верхнем регистре

Константа - это переменная с неизменным значением. Если вы работаете с константой, то лучшая практика - это написать ее имя полностью в верхнем регистре (типичное соглашение в JavaScript).

Префиксы из одной буквы

Если перед именем переменной стоит одна буква, например, "s" или "i", то это "Венгерская нотация" - соглашение, которое напоминает разработчику о том, с каким типом данных он работает: строка, целое число и т.д.

"Венгерская нотация" в значительной степени утратила свою популярность, хотя все еще применяется достаточно часто.

Следует отметить тот факт, что в мире JavaScript данная практика скорее не одобряется, т.к. JavaScript - это свободно типизируемый язык.

Почему это важно?

Представьте, что мы, используя вышеописанное соглашение, объявили переменную для хранения строковых данных, используя префикс "s", а после этого решили сменить значение переменной на число.

В этом случае использование данного соглашения введет нас в заблуждение.

[свернуть]

Символ доллара в именах переменных и констант

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

Использовать ли вам его? Как хотите. Просто сформируйте свое собственное мнение на этот счет.

Большая первая буква в именах переменных и констант

В коде выше переменная $SomeClass капитализирована, так как это имя класса, а не имя переменной. Опять-таки, это соглашение об именовании, которого придерживаются большинство разработчиков.

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

Для чего мы капитализируем имя объекта Person? Делается это потому, что мы можем легко забыть использовать слово new. В этих условиях JavaScript не будет выдавать нам никаких предупреждений, и поиск ошибок будет затруднен.

CamelCase (ВерблюжьяНотация) против under_score (нижнего_подчеркивания)

Правильного подхода нет: это целиком зависит от языка и от стандартов кодирования, которых придерживается какая-либо организация или человек. Оба варианта приемлемы.

К примеру, большинство разработчиков на JavaScript используют верблюжью нотацию, в том время как в других языках, вроде PHP, есть тенденция к применению нижнего подчеркивания для разделения слов. Однако опять же, это не догма.

Организация структуры папок

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

Многие разработчики предпочитают помещать все картинки, скрипты и стилевые файлы в папку с именем Assets.

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

Семантика кода

При создании разметки, надеюсь, это всем понятно, идентификаторы и классы, которые Вы выбираете, должны описывать тип содержимого, а не презентационные аспекты (особенности позиционирования и внешнего вида).

Отвратительно:

Лучше:

Отлично:

С переходом на HTML5 следует все меньше использовать идентификаторы для элементов. Идентификаторы не очень гибки и, во многих случаях, необязательны.

Двойные хэдеры и футеры

Вспомните. Когда Вы создаете сайт с центрированным дизайном, у которого должно быть несколько фонов, которые занимают всю доступную ширину экрана (обычно для хэдера и футера), Вы обычно создаете "обертку" для зоны контента, чтобы внешние элементы могли расширяться, в то время как внутренний элемент оставался бы центрированным.

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

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

Элементы div следует использовать только, если:

  • нет более подходящего элемента для конкретной задачи;
  • вам нужен элемент исключительно для структурирования макета страницы

Сокращения кода (читабельность против объема)

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

Тернарный оператор:

Логическое && для условий:

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

Отсюда

Добавить комментарий

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.