• Главная
• Видеоуроки
• PHP
• JavaScript
• CSS
• HTML
• Сервисы
• Статьи
• Оффтоп

• Главная
• ->
• Материалы
• ->
• 9 сбивающих с толку соглашений об именовании

9 сбивающих с толку соглашений об именовании

Когда Вы только начинаете осваивать различные языки в мире веб-разработки, то очень трудно сразу запомнить все соглашения об именовании, которые в них приняты.

Еще большая путаница возникает, если опытные разработчики сами не могут договориться о том, что считать "лучшей практикой".

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

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

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

PHP

// Эта переменная недоступна из-за пределов класса
private $_someVariable;

class MyClass {
   // Этот метод доступен только из этого класса,
   // либо из классов, его наследующих
   protected function __behindTheScenesMethod() {}
}

Заметьте, что в коде выше нижнее подчеркивание - это не то, что превращает свойство или метод в private или protected; для этого используются соответствующие спецификаторы доступа: private и protected. Нижнее подчеркивание - это просто напоминание для Вас, чтобы через полгода Вам было проще ориентироваться.

JavaScript

var Female = (function() {
   var _trueAge = 50,
       _trueWeight = 140;

   return {
      age : _trueAge - 15,
      weight : _trueWeight - 30
   };
})();

Female.age; // 35
Female.weight; // 110
Female._trueAge; // undefined (потому что она private)

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

2. ВЕРХНЕРЕГИСТРОВЫЕ константы

Константа - это переменная с неизменным значением (звучит странно, но это так:))

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

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

JavaScript

var TAXRATE = .0825;

PHP

define('TAXRATE', .0825);

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

Вы наверняка где-нибудь уже видели переменную, перед именем которой стояла одна буква, например, "s" или "i".

$sName = 'Капитан Jack Sparrow';

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

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

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

Свободно типизируемый язык - это язык, который не требует от Вас объявления типа данных, используемого для конкретной переменной.

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

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

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

var sName="Великий князь московский и Всея Руси...";
typeof(sName); // string
....
sName = undefined;
typeof(sName) // undefined

Символ доллара

Для тех, кто использует jQuery: Прежде чем Вы запрыгнете на пьедестал почета, радуясь, что не используете это соглашение, спросите себя, используете ли Вы символ доллара для переменных внутри объекта jQuery?

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

// Символ доллара напоминает мне о том, что эта переменная
// имеет доступ к различным методам jQuery
var $container = $('#container');

Использовать ли Вам его?

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

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

4. Большая Первая Буква

Как насчет тех имен "переменных", у которых капитализируется первая буква?

$response = $SomeClass->doSomething();

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

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

// Заметьте большую "M" в имени класса.
class MyClass {
   function __construct() {}
}

JavaScript

var Jeff = new Person();

Для чего мы капитализируем имя объекта Person?

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

5. ВерблюжьяНотация против нижнего_подчеркивания

Почему в одних случаях мы видим использование верблюжьей нотации, а в других - нижнего подчеркивания для разделения слов? Какой подход является правильным?

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

// ВерблюжьяНотация
var preacherOfSockChanging = 'Lieutenant Dan';

// нижнеее_подчеркивание
var preacher_of_sock_changing = 'Lieutenant Dan';

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

"Не так важно, что Вы используете, как то, чтобы Вы придерживались этого!"

6. Структура папок

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

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

/ Project Root
  /Assets
    / js
      / min
        script_min.js
      script.js
    / css
      / min
        style_min.css
      style.css
    / img
      img1.jpg
  index.html
  otherFile.html

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

7. Семантика

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

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

<div id="middle-left-and-then-a-little-lower">Justin Bieber is my homeboy section.</div>

Лучше:

<div class="section">Justin Bieber is my homeboy section.</div>

Отлично:

<section>Justin Bieber is my homeboy section.</section>

Как же так?

Что будет, если через полгода Вы захотите поместить вашего Джастина Бибера в "middle-RIGHT-and-then-a-little-lower" секцию? В этом случае имя вашего класса будет, мягко говоря, странноватым.

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

8. Двойные Хэдеры и Футеры

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

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

<div id="footer-wrap">
	<footer>
	  Содержимое футера.
	</footer>
</div>

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

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

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

9. Сокращения

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

Именно поэтому очень важно, чтобы все в команде разработчиков следовали один и тем же стандартам кодирования. Рассмотрим пару примеров:

А Вы дружите с тернарным оператором?

var name = 'Joe';

// классический подход
if ( name === 'Jeff' ) {
  alert("Это я");
} else {
  alert("Неа");
}

// применение тернарного оператора
(name === 'Jeff') ? alert("Это я") : alert("Неа"); // Неа

Как насчет логического && для условий?

var getTweets = true;

// классический подход
if ( getTweets ) {
 alert('getting them now');
}

// Логическое И (AND)
// То, что справа, не будет исполнено, если то, что слево не явяется истиной
getTweets && alert('Getting them now');

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

Итог

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

По материалам net.tutsplus.com
Перевод - Дмитрий

P.S. Присмотритесь к премиум-урокам по различным аспектам сайтостроения, а также к бесплатному курсу по созданию своей CMS-системы на PHP с нуля. Все это поможет вам быстрее и проще освоить JavaScript, PHP и другие языки веб-разработки:

Понравился материал и хотите отблагодарить?
Просто поделитесь с друзьями и коллегами!

Смотрите также:

Наверх