Статьи

9 Непонятные соглашения об именах для начинающих

Январь 21, 2019

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

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

Когда вы сталкиваетесь с переменной или методом, который обрабатывается _ , за кулисами не происходит никакой магии вуду. Это просто соглашение об именах, которое напоминает разработчику, что переменная / свойство / метод является либо private либо protected , и к ней нельзя получить доступ извне класса.

Метод PHP

1
2
3
4
5
6
7
8
// This variable is not available outside of the class
private $_someVariable;
 
class MyClass {
   // This method is only available from within this class, or
   // any others that inherit from it.
   protected function __behindTheScenesMethod() {}
}

Обратите внимание, что в приведенном выше коде подчеркивание не является тем, что делает переменную или метод private ; ключевое слово private/protected делает это. Подчеркивание — это всего лишь напоминание о предстоящем полугодии!

Метод JavaScript

01
02
03
04
05
06
07
08
09
10
11
12
13
var Person = (function() {
   var _trueAge = 50,
        _trueWeight = 140;
 
   return {
      age : _trueAge — 15,
      weight : _trueWeight — 30
   };
})();
 
Person.age;
Person.weight;
Person._trueAge;

Делая Person равным не function , а возвращаемому object , мы можем создавать частные переменные. И снова префикс подчеркивания напоминает нам об этом.

2. Верхние константы

constant — это переменная со статическим значением, которая не изменится. Например, если ваш проект требовал умножения значения на государственную пошлину, вы можете присвоить эту ставку, $.0825 constant . Однако не во всех языках встроены эти типы переменных. Поэтому рекомендуется использовать все заглавные буквы, чтобы напомнить себе, что вы работаете с constant . Это общее соглашение в мире JavaScript, и используются его нативные объекты, такие как MATH.PI

Метод JavaScript 

  var TAXRATE = .0825;

Метод PHP

1
define(‘TAXRATE’, .0825);

3. Однобуквенные префиксы

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

1
$sName = ‘Captain Jack Sparrow’;

Это называется Hungarian notation и в последние годы перестало пользоваться популярностью, хотя многие компании все еще используют эту конвенцию.

Венгерская нотация — это соглашение об именах, которое напоминает разработчику о type переменной, с которой он работает: s tring , i nteger и т. Д.

В частности, в мире JavaScript эта практика не одобряется из-за того, что это слабо типизированный язык. Свободно типизированный язык — это язык, который не требует, чтобы вы объявляли тип данных переменной. Почему это важно? Что если, используя соглашение о нотации выше, мы объявили строку с префиксом "s" , но затем изменили переменную на целое число? В этот момент эта форма записи будет работать против нас, а не против нас. 

  var sName = "Лейтенант-коммандер Джорджи Ла Форж";
 TypeOf (зЫат);  // строка
 ....
 sName = не определено;
 typeof (sName) // не определено

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

Пользователи jQuery: перед тем, как встать на пьедестал и похвалить себя за то, что вы не используете эту форму записи, спросите себя, префиксные ли вы переменные — завернутые в объект jQuery — символом доллара? Если так, то это форма венгерской нотации. Это символ, начинающийся с имени переменной, который служит единственной цели информирования вас о типе или качестве переменной. 

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

Вы должны использовать это?

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

4. Заглавная первая буква

Как насчет тех «переменных» имен, которые пишут с заглавной буквы первую букву имени?

1
$response = $SomeClass->doSomething();

В приведенном выше коде $SomeClass буквы, потому что это class а не имя variable . Опять же, это соглашение об именах, которое используют большинство разработчиков. Возвращаясь к коду год спустя, это небольшая лампочка, которая сообщает им, что они работают с классом, у которого есть доступные объекты и методы.

1
2
3
4
// Note the capital M in the class name.
class $MyClass {
   function __construct() {}
}

Мир JavaScript

В JavaScript у нас действительно нет class es; но у нас есть функции constructor . 

  var Jeff = new Person ();

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

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

  function Person (имя) {
   // Если новое ключевое слово отсутствует, конструктор будет окном.
   // В этом случае компенсируем и возвращаем новый экземпляр
   if (this.constructor! == Person) {
     вернуть новое лицо (имя);
   }
  this.name = имя;
 }

 // Намеренно забыл "новое" ключевое слово 
 var Joey = Person ('Joey');
 Joey.name;  // Джо

5. CamelCase против under_score

Почему некоторые переменные используют шаблон camelCase, а другие используют подчеркивание для разделения слов? Какой правильный метод? Ответ: нет правильного использования. Это полностью зависит от языка и / или правил кодирования вашей компании. Оба вполне приемлемы. 

  // camelCase
 var preacherOfSockChanging = 'Лейтенант Дан';

 // подчеркивать
 var preacher_of_sock_changing = 'лейтенант Дан';

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

Более важным, чем то, что вы используете, является обеспечение его соблюдения

6. Структура каталогов

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

  / Корень проекта
   / Активы
     / JS
       / мин
         script_min.js
       script.js
     / CSS
       / мин
         style_min.css
       style.css
     / img
       img1.jpg
   index.html
   otherFile.html

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

7. Семантика

Надеемся, что при создании разметки широко понимается, что id и class вы выбираете, должны описывать тип контента, а не аспекты представления. В качестве примера:

Действительно плохо

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

Лучше

1
<div class=»section»> Justin Bieber is my homeboy section.

Лучший

1
<section> Justin Bieber is my homeboy section.

Как придешь? Что если через шесть месяцев вы решите разместить свою секцию поклонников Джастина Бибера в средней, правой, а затем и чуть более низкой секции? На этом этапе ваш id будет иметь мало смысла.

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

8. Двойной Header и Footer

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

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

1
2
3
4
5
<div id=»footer-wrap»>
    <footer>
      My footer content goes here.
    </footer>
</div>

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

div s следует использовать только когда:

  • Там нет лучшего элемента для работы
  • Когда вам нужен элемент просто структурировать макет

9. Ярлыки

Решите сейчас, разрешите ли вы использовать ярлыки в своем коде. Написание точного / чистого кода — это всегда битва читабельности и размера. Вот почему крайне важно, чтобы команды разработчиков следовали одним и тем же правилам кодирования. Чтобы привести два быстрых примера:

С тобой тройной оператор в порядке? 

  var name = 'Джо';

 // обычный
 if (name === 'Jeff') {
   оповещение («Это я»);
 } еще {
   предупреждение ( "Нео");
 }

 // троичный
 (имя === 'Джефф')?  alert («Это я»): alert («Нет»);  // Нет

А как насчет логических && для условных сокращений? 

  var getTweets = true;

 // обычный
 if (getTweets) {
  оповещение («получить их сейчас»);
 }

 // Логическое И
 // Правая сторона не будет работать, если левая сторона не равна "true"
 getTweets && alert ('Получение их сейчас');

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

Вывод

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

35
Share: