Latest Posts

НТМL — HyperText Markup Language

CSS — Cascading Style Sheets

JavaScript — programming language of HTML and the Web

PHP — Hypertext Preprocessor

Стандарты кодирования WordPress

Целью установления стандартов кодирования сообщество WordPress разработало стандарты которым рекомендуется следовать всем разработчикам.
Зачем нужны стандарты кодирования?

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

Стандарты кодирования НТМL

Валидация

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

Самозакрывающиеся элементы

Все теги должны быть правильно закрыты. Для тегов, которые служат оберткой для узлов, таких как текст или другие элементы, закрытие — это достаточно тривиальная задача. Одиночные теги должны быть закрыты с помощью косой черты, перед которой должен идти один пробел:

<br />

Следующий вариант является более компактным, но некорректным:

<br/>

W3C указывает, что закрывающей косой черте должен предшествовать ровно один пробел

Атрибуты и Теги

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

Для машин:

<meta http-equiv=»content-type» content=»text/html; charset=utf-8″ />

Для человека:

<a href=»http://example.com/» title=»Description Here»>Example.com</a>

Кавычки

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

Правильно:

<input type=»text» name=»email» disabled=»disabled» />
<input type=’text’ name=’email’ disabled=’disabled’ />

Неправильно:

<input type=text name=email disabled>

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

Отступы

Как и в случае с PHP, в HTML отступы должны всегда отражать логическую структуру. Используйте для этого табуляции, а не пробелы.

При смешивании кодов PHP и HTML, отступы PHP-блоков должны быть в соответствии с окружающим HTML-кодом. Закрывающие PHP-блоки должны иметь те же отступы, что и открывающие.

Правильно:

<?php if ( ! have_posts() ) : ?>
<div id=»post-1″ class=»post»>
<h1 class=»entry-title»>Not Found</h1>
<div class=»entry-content»>
<p>Apologies, but no results were found.</p>
<?php get_search_form(); ?>
</div>
</div>
<?php endif; ?>

Неправильно:

<?php if ( ! have_posts() ) : ?>
<div id=»post-0″ class=»post error404 not-found»>
<h1 class=»entry-title»>Not Found</h1>
<div class=»entry-content»>
<p>Apologies, but no results were found.</p>
<?php get_search_form(); ?>
</div>
</div>
<?php endif; ?>

Стандарты кодирования CSS

Как и для любых других стандартов кодирования целью формирования стандартов кодирования CSS в WordPress является создание основы для сотрудничества и контроля в рамках различных аспектов проекта и сообщества WordPress, от основного кода до тем и плагинов. Файлы в проекте должны выглядеть так, как будто созданы одним разработчиком. Прежде всего, создавайте код, который будет читаемым, существенным, последовательным и красивым.

Внутри основной таблицы стилей часто будут обнаруживаться несоответствия. Мы работаем над решением этих проблем и прилагаем максимум усилий, чтобы патчи с этого момента соответствовали стандартам кодирования CSS. Подробная информация по данной теме и о вкладе в UI/front-end разработку будет изложена в виде отдельного набора инструкций.

Структура

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

• Используйте табуляции, а не пробелы для отступа у каждого свойства.
• Добавляйте две пустые строки между разделами и одну пустую строку между блоками в разделе.
• Каждый селектор должен находиться на отдельной строке, заканчивающейся либо запятой, либо открывающей фигурной скобкой. Каждая пара свойство-значение должна быть на отдельной строке, с отступом в одну табуляцию и с точкой с запятой в конце. Закрывающая фигурная скобка должна быть на том же уровне слева, что и открывающий селектор.

Правильно:

#selector-1,
#selector-2,
#selector-3 {
background: #fff;
color: #000;
}

Неправильно:

#selector-1, #selector-2, #selector-3 {
background: #fff;
color: #000;
}
#selector-1 { background: #fff; color: #000; }

Селекторы

Со специфичностью связано больше ответственности. Общие селекторы позволяют нам быть эффективными, но могут иметь отрицательные последствия, если не выполнено тщательное тестирование. Более специфичные селекторы могут сохранить нам время, но быстро приведут к сумбуру в таблице стилей. Опыт — лучший помощник для нахождения правильного баланса между общими стилями и шаблоном DOM.

• Для имен селекторов, используйте слова в нижнем регистре, разделенные дефисами. Избегайте CamelCase-нотации и знаков подчеркивания.
• Используйте удобочитаемые селекторы, описывающие элементы, к которым они применяются.
• Для значений атрибутов селекторов используйте двойные кавычки.
• Воздерживайтесь от использования слишком детальных селекторов, вместо div.container можно просто указать .container.

Правильно:
#comment-form {
   margin: 1em 0;
}

input[type=»text»] {
   line-height: 1.1;
}

Неправильно:

#commentForm { /* Избегайте CamelCase-нотации. */
   margin: 0;
}
#comment_form { /* Избегайте знаков подчеркивания. */
   margin: 0;
}
div#comment_form { /* Избегайте излишней детализации. */
   margin: 0;
}
#c1-xr { /* Что значит c1-xr?! Используйте осмысленное имя. */
   margin: 0;
}
input[type=text] { /* Должно быть [type=»text»] */
   line-height: 110% /* Вдвойне неправильно */
}

Свойства

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

• За свойством должны идти двоеточие и пробел.
• Все свойства и значения должны быть в нижнем регистре, за исключением названий шрифтов и нестандартных свойств разработчиков.
• Используйте шестнадцатеричные коды для цветов или rgba(), если нужна прозрачность. Избегайте формата RGB и прописных букв и сокращайте значения, если это возможно: #fff вместо #FFFFFF.
• Максимально используйте универсальные свойства (за исключением случаев, когда это приводит к переопределению стилей) для фона, границ, шрифтов, стилей списка, полей и отступов. (См. краткий справочник CSS Shorthand).

Упорядочение свойств

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

• Отображение
• Позиционирование
• Блочная модель
• Цвета и шрифты
• Другие

Top/Right/Bottom/Left (TRBL/trouble) — порядок для любых соответствующих свойств (например, margin). Свойства углов (например, border-radius-*-*) должны идти в порядке: top-left, top-right, bottom-right, bottom-left. Эти правила следуют из того, как указываются универсальные свойства.

Пример:

#overlay {
   position: absolute;
   z-index: 1;
   padding: 10px;
   background: #fff;
   color: #777;
}

Другой метод, который часто используется, в том числе и группой Automattic/WordPress.com Themes, состоит в упорядочивании свойств по алфавиту, с некоторыми исключениями или без них.

Пример:

#overlay {
   background: #fff;
   color: #777;
   padding: 10px;
   position: absolute;
   z-index: 1;
}

Префиксы разработчиков

Мы используем grunt-autoprefixer в качестве инструмента предварительной обработки, чтобы легко управлять необходимыми для браузеров префиксами, таким образом делая большую часть этой спорной работы. Для тех, кому интересно, каким должен быть выход без использования Grunt, префиксы разработчиков должны идти от длинных (-webkit-) к коротким (без префикса). Остальные правила упорядочивания стандартны.

.sample-output {
   -webkit-box-shadow: inset 0 0 1px 1px #eee;
   -moz-box-shadow: inset 0 0 1px 1px #eee;
   box-shadow: inset 0 0 1px 1px #eee;
}

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

• Пробел перед значением, после двоеточия.
• Не ставьте лишних пробелов около скобок.
• Всегда ставьте конечную точку с запятой.
• Используйте двойные кавычки, а не одинарные, и только при необходимости, например, если имя шрифта содержит пробелы.
• Нулевые значения не должны иметь единиц, за исключением случаев, когда они необходимы, например с transition-duration.
• Высота строки должна быть безразмерной, за исключением случаев, когда она должна быть определена как конкретное значение в пикселях. Это не просто соглашение о стиле, но об этом стоит здесь упомянуть.
• Используйте ведущий нуль для десятичных значений, в том числе в rgba().
• Несколько разделенных запятыми значений для одного свойства должны быть разделены либо пробелом, либо переводом строки, в том числе в rgba(). Переводы строк должны быть использованы для длинных составных значений, таких как сокращенные свойства, подобные box-shadow или text-shadow. Каждое последующее значение после первого должно располагаться на новой строке, выровненное по левому краю с предыдущим значением.

Правильно:

.class { /* Правильное использование кавычек */
   background-image: url(images/bg.png);
   font-family: «Helvetica Neue», sans-serif;
}

.class { /* Правильное использование нулевых значений */
   font-family: Georgia, serif;
   text-shadow: 0 -1px 0 rgba(0, 0, 0, 0.5),
                0 1px 0 #fff;
}Неправильно:

.class { /* Избегайте пропускать конечную точку с запятой  */
   background:#fff
}
.class { /* Избегайте добавлять единицу измерения к нулевым значениям */
   margin: 0px 0px 20px 0px;
}

Указание типа носителя

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

Вообще, желательно размещать команды @media, сгруппированные по типу носителя, в нижней части таблицы стилей. Исключение составляет файл wp-admin.css в ядре, так как он очень большой, и каждый раздел по существу представляет собой отдельную таблицу стилей. Поэтому команды @media следует добавлять в конец соответствующих разделов. Наборы стилевых правил должны быть сдвинуты на один уровень внутрь.
Пример:

@media all and (max-width: 699px) and (min-width: 520px) {

       /* Your selectors */
}

Комментарии

• Комментируйте и комментируйте подробно. Если есть опасения по поводу размера файла, используйте сжатые файлы и постоянную SCRIPT_DEBUG. Длинные комментарии должны вручную разбиваться на строки длиной в 80 символов.
• Для больших стилевых файлов должно использоваться оглавление, особенно если файл содержит большое количество разделов. Используйте индексацию (1.0, 1.1, 2.0 и т.д.) для поиска и перемещения по стилевому файлу.
• Комментарии должны быть отформатированы в соответствии со стандартом PHPDoc. CSSDoc не обязателен к использованию, но некоторые его аспекты могут быть приняты с течением времени. Заголовки разделов/подразделов должны иметь переводы строк до и после них. Inline-комментарии не должны иметь переводов строки, отделяющих комментарий от элемента, к которому он относится.

Заголовки разделов и подразделов:

/**
* #.# Заголовок раздела
*
* Описание раздела, имеет ли он команды media и т.д.
*/

.selector {
   float: left;
}

Inline-комментарии:

/* Комментарий, описывающий селектор */

.another-selector {
   position: absolute;
   top: 0 !important; /* Объяснение, почему используется !important */
}

Стандарты кодирования Javascript

JavaScript стал важным звеном в развитии WordPress-приложений (тем и плагинов), а также ядра WordPress. Для форматирования и стилизации кода JavaScript необходимы стандарты, чтобы сохранить ту же согласованность, которую стандарты кодирования WordPress обеспечивают для PHP, HTML и CSS кода.

Cтандарты кодирования JavaScript для WordPress развиты на основе jQuery JavaScript Style Guide. Наш стандарт отличается от руководства для jQuery в следующих моментах:

• WordPress использует одинарные кавычки для строк.
• Директивы case сдвигаются на отступ внутри блоков switch.
• Тело функции всегда оформляется отступом.
• Есть некоторые отличия в использовании пробелов для согласованности со стандартами кодирования PHP.
• 100-символьный лимит jQuery приветствуется, но не является строго обязательным.

Интервалы
Активно используйте пробелы в вашем коде. «Если сомневаетесь, ставьте пробел.»
Эти правила рекомендуют максимальное использование интервалов для улучшения читабельности. С помощью минимизации можно создать файл, который оптимизирован для чтения и обработки браузерами.

• Оформляйте отступы с помощью табуляций.
• Не используйте пробелы в конце строк и в пустых строках.
• Строки обычно пишутся не длиннее 80 символов и определенно не должны превышать 100 (считая каждую табуляцию за 4 пробела). Это нежесткое правило, но длинные строки обычно указывают на нечитабельный или плохо организованный код.
• if/else/for/while/try блоки должны всегда использовать фигурные скобки и располагаться на нескольких строках.
• Унарные операторы (например, ++, —) не должны иметь пробелов после своих операндов.
• Перед , и ; не должно быть пробелов.
• Любая ; как признак конца команды должна быть в конце строки.
• Перед : после имени свойства в определении объекта не должно быть пробелов.
• Знаки ? и : в тернарном условном операторе должны иметь пробелы с обеих сторон.
• В пустых конструкциях (например, {}, [], fn()) не должно быть заполняющих пробелов.
• Должна быть новая строка в конце каждого файла.
• За знаком оператора отрицания ! должен идти пробел.
• Тело функции оформляется отступом в одну табуляцию.
• Пробелы могут использоваться для выравнивания кода в документированных блоках или в строках, но для отступов в начале строки должны использоваться только табуляции.

Стандарты JavaScript-кода в WordPress предполагают несколько более широкое использование пробелов, чем в стандартах jQuery. Эти изменения приняты для согласованности между PHP и JavaScript-кодом в WordPress.

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

Объекты
Объявление объекта может располагаться на одной строке, если оно достаточно короткое (вспомните о рекомендациях по поводу длины строк). Если объявление объекта слишком длинное и не помещается на одной строке, тогда каждое свойство должно располагаться на отдельной строке. Имена свойств должны заключаться в кавычки только, если они являются зарезервированными словами или содержат специальные символы:

// Предпочтительно
var map = {
   ready: 9,
   when: 4,
   ‘you are’: 15
};
// Приемлемо для небольших объектов
var map = { ready: 9, when: 4, ‘you are’: 15 };

// Плохо
var map = { ready: 9,
   when: 4, ‘you are’: 15 };

Массивы и вызовы функций
Всегда ставьте дополнительные пробелы вокруг элементов и аргументов:
array = [ a, b ];
foo( arg );
foo( ‘string’, object );
foo( options, object[ property ] );
foo( node, ‘property’, 2 );
Исключения:
// Для обеспечения согласованности с PHP-стандартами не ставьте пробелов вокруг
// строковых литералов или целых чисел, используемых в качестве ключей в массивах
prop = object[‘default’];
firstArrayElement = arr[0];
// Функция, единственным аргументом которой является callback-функция, объект или массив
// По обе стороны аргумента пробелов быть не должно
foo(function() {
   // Do stuff
});
foo({
   a: «Альфа»,
   b: ‘бета’
});
foo([
   «Альфа»,
   ‘бета’
]);
// Если первым аргументом функции является callback-функция, объект или массив,
// то перед первым аргументом не должно быть пробелов
foo(function() {
   // Do stuff
}, options );

// Если последним аргументом функции является callback-функция, объект или массив,
// то после последнего аргумента не должно быть пробелов
foo( data, function() {
   // Do stuff
});

Примеры правильной расстановки пробелов
var i;

if ( condition ) {
   doSomething( ‘with a string’ );
} else if ( otherCondition ) {
   otherThing({
       key: value,
       otherKey: otherValue
   });
} else {
   somethingElse( true );
}
// В отличие от jQuery в WordPress после оператора ! должен идти пробел.
// Это сделано также для согласованности с PHP-стандартами.
while ( ! condition ) {
   iterating++;
}

for ( i = 0; i < 100; i++ ) {
   object[ array[ i ] ] = someFn( i );
   $( ‘.container’ ).val( array[ i ] );
}
try {
   // Выражения
} catch ( e ) {
   // Выражения
}

Точки с запятой
Используйте их. Никогда не полагайтесь на автоматическую вставку (ASI).

Отступы и переносы строк

Отступы и переносы строк добавляют читабельности для сложных конструкций.

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

(function( $ ) {
   // Выражения с отступом

   function doSomething() {
       // Выражения с отступом
   }
})( jQuery );

Блоки и фигурные скобки
if, else, for, while, try — блоки должны всегда использовать фигурные скобки, и всегда располагаться на нескольких строках. Открывающая скобка должна быть в одной строке с определением функции, условием или началом цикла. Закрывающая скобка должна быть в строке, непосредственно следующей за последним оператором блока.

var a, b, c;

if ( myFunction() ) {
   // Выражения
} else if ( ( a && b ) || c ) {
   // Выражения
} else {
   // Выражения
}

Многострочные предложения
Когда предложение слишком длинное для одной строки, переносы строк должны вставляться после операторов.

// Плохо
var html = ‘<p>The sum of ‘ + a + ‘ and ‘ + b + ‘ plus ‘ + c
   + ‘ is ‘ + ( a + b + c );

// Хорошо
var html = ‘<p>The sum of ‘ + a + ‘ and ‘ + b + ‘ plus ‘ + c +
   ‘ is ‘ + ( a + b + c );
Строки должны разбиваться на логические группы, если это улучшает читабельность, например, каждое выражение тернарного оператора лучше помещать на свою строку, даже если оба помещаются на одной строке:

// Приемлемо
var baz = ( true === conditionalStatement() ) ? ‘thing 1’ : ‘thing 2’;

// Лучше
var baz = firstCondition( foo ) && secondCondition( bar ) ?
   qux( foo, bar ) :
   foo;
Когда условние слишком длинное и не помещается на одной строке, последующие строки должны быть с отступом на один дополнительный уровень, чтобы отличить их от основного кода.

if ( firstCondition() && secondCondition() &&
       thirdCondition() ) {
   doStuff();
}

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

elements
   .addClass( ‘foo’ )
   .children()
       .html( ‘hello’ )
   .end()
   .appendTo( ‘body’ );

Присваивания и глобальные переменные
Объявление переменных с помощью var
Каждая функция должна начинаться с объявления переменных с помощью ключевого слова var, за которым через запятую следуют необходимые локальные переменные. Если переменная не объявляется с помощью var, она может проникнуть во внешнюю область (в худшем случае, в глобальную область видимости) и невольно привести к модификации данных.

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

// Хорошо
var k, m, length,
   // Дополнительная строка сдвинута на один отступ
   value = ‘WordPress’;

// Плохо
var foo = true;
var bar = false;
var a;
var b;
var c;

Глобальные переменные
В прошлом код WordPress затруднял использование глобальных переменных. Поскольку JavaScript-файлы ядра иногда используются в плагинах, существующие глобальные переменные не должны удаляться. Все глобальные переменные, используемые в файле, должны быть задокументированы в верхней части этого файла. Несколько глобальных переменных можно перечислить через запятую. Этот пример делает passwordStrength разрешенной глобальной переменной внутри файла:

/* global passwordStrength:true */
true после passwordStrength означает, что эта глобальная переменная определяется в пределах этого файла. Если вы обращаетесь к глобальной переменной, определенной в другом месте, опустите :true, чтобы указать, что глобальная переменная используется только для чтения.

Распространенные библиотеки

Backbone, jQuery, Underscore и глобальный объект wp зарегистрированы как разрешенные глобальные переменные в корневом .jshintrc — файле. К Backbone и Underscore можно обратиться непосредственно в любом месте. jQuery доступна через $ при передаче jQuery-объекта в анонимную функцию:

(function( $ ) {
 // Выражения
})( jQuery );
Это позволяет избежать необходимости вызова .noConflict() или установки псевдонима с помощью другой переменной. Файлы, которые добавляют или изменяют объект wp, должны безопасно обращаться к глобальному объекту, чтобы избежать перезаписи ранее установленных свойств:

// В начале файла присвойте «wp» существующее значение (если оно есть)
window.wp = window.wp || {};

Соглашения об именовании
Переменных и имена функций должны быть целыми словами. Используйте camelCase-нотацию со строчной первой буквой. Это область, где этот стандарт отличается от стандартов кодирования PHP в WordPress .

Конструкторы, предназначенные для использования с new, должны иметь прописную первую букву (UpperCamelCase).

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

Комментарии
Комментарии должны предшествовать коду, к которому они относятся. Перед комментарием должна идти пустая строка. Начинайте комментарий с прописной буквы. Ставьте точку в конце, если комментарий является законченным предложением. Между символом комментария (//) и текстом комментария должен быть один пробел.

Однострочный комментарий:

someStatement();

// Объяснение чего-то сложного в следующей строке
$( ‘p’ ).doSomething();

Для длинных комментариев используйте многострочные комментарии:

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

function foo( types, selector, data, fn, /* INTERNAL */ one ) {
   // Делать что-то
}

Равенство
Строгая проверка на равенство (===) должна использоваться вместо простой проверки (==). Единственным исключением является ситуация, когда осуществляется проверка на undefined или null путем проверки на равенство null.

// Проверка undefined и null-значений по каким-то важным причинам.
if ( undefOrNull == null ) {
   // Выражения
}

Проверка типа
Ниже приведены предпочтительные способы проверить тип объекта:

• Строка: typeof object === ‘string’
• Число: typeof object === ‘number’
• Логический тип: typeof object === ‘boolean’
• Объект: typeof object === ‘object’ или _.isObject( object )
• Простой объект: jQuery.isPlainObject( object )
• Функция: _.isFunction( object) или jQuery.isFunction( object )
• Массив: _.isArray( object ) или jQuery.isArray( object )
• Элемент: object.nodeType или _.isElement( object )
• null: object === null
• null или undefined: object == null
• undefined:
  • Глобальная переменная: typeof variable === ‘undefined’
  • Локальная переменная: variable === undefined
  • Свойство: object.prop === undefined
  • Любое из вышеперечисленных: _.isUndefined( object )

Всюду, где используется Backbone или Underscore, рекомендуется использовать проверку типов Underscore.js вместо jQuery.

Строки
Используйте одинарные кавычки для строковых литералов:

var myStr = ‘строки должны заключаться в одинарные кавычки’;
Когда строка содержит одинарные кавычки, они должны быть экранированы символами обратной косой черты (\):

// Экранируйте одиночные кавычки внутри строки:
‘Note the backslash before the \’single quotes\»;

Switch
Использование конструкции switch, как правило, не рекомендуется, но может быть полезно, когда существует большое количество вариантов case, особенно если несколько вариантов могут быть обработаны в одном блоке, или вариант default может быть использован.

При использовании конструкции switch:

• Используйте break; для каждого варианта case, отличного от default. При группировке case отмечайте это явным образом.
• Сдвигайте варианты case на одну табуляцию по сравнению со switch.

switch ( event.keyCode ) {

   // ENTER и SPACE оба вызывают x()
   case $.ui.keyCode.ENTER:
   case $.ui.keyCode.SPACE:
       x();
       break;
   case $.ui.keyCode.ESCAPE:
       y();
       break;
   default:
       z();
}
Не рекомендуется возвращать значение из оператора switch: используйте блоки case, чтобы сохранить значение, а затем в конце верните значение с помощью return.

function getKeyCode( keyCode ) {
   var result;

   switch ( event.keyCode ) {
       case $.ui.keyCode.ENTER:
       case $.ui.keyCode.SPACE:
           result = ‘commit’;
           break;
       case $.ui.keyCode.ESCAPE:
           result = ‘exit’;
           break;
       default:
           result = ‘default’;
   }

   return result;
}

Практические рекомендации
Массивы
Массивы в JavaScript следует создавать, используя сокращенный конструктор [], а не вызовом new Array().

var myArray = [];
Вы можете инициализировать массив при создании:

var myArray = [ 1, ‘WordPress’, 2, ‘Blog’ ];
В JavaScript ассоциативные массивы определяются как объекты.

Объекты
Существует много способов создания объектов в JavaScript. Литеральная нотация {} является как наиболее удобной, так и более читабельной.
var myObj = {};
Литеральная нотация объекта должна использоваться, если объект не требует прототипа. Иначе объект должен быть создан с помощью вызова конструктора new.
var myObj = new ConstructorMethod();
Свойства объекта должны быть доступны через точечную нотацию, если ключ не является переменной, зарезервированным словом или строкой, которая не может быть идентификатором:
prop = object.propertyName;
prop = object[ variableKey ];
prop = object[‘default’];
prop = object[‘key-with-hyphens’];

Функции Underscore.js для коллекций
Изучите методы Underscore для коллекций и массивов. Эти функции, в том числе _.each, _.map , _.reduce, позволяют эффективно и наглядно преобразовывать большие наборы данных.
Underscore также допускает написание цепочек объектов JavaScript в стиле Query:
var obj = {
   first: ‘thing 1’,
   second: ‘thing 2’,
   third: ‘lox’
};
var arr = _.chain( obj )
   .keys()
   .map(function( key ) {
       return key + ‘ comes ‘ + obj[ key ];
   })
   // Окончание цепочки
   .value();
// arr === [ ‘first comes thing 1’, ‘second comes thing 2’, ‘third comes lox’ ]Перебор коллекции jQuery
Единственный случай, когда jQuery должен использоваться для перебора, — это работа с коллекцией jQuery-объектов:
$tabs.each(function( index, element ) {
   var $element = $( element );
   // Делать что-то с $element
});
Никогда не используйте jQuery, чтобы перебирать исходные данные или обычные объекты JavaScript.

Стандарты кодирования PHP

Одиночные и двойные кавычки

Используйте одинарные и двойные кавычки, когда это необходимо. Если вы не оцениваете ничего в строке, используйте одинарные кавычки. Почти никогда не следует избегать кавычек в строке, потому что вы можете просто чередовать тип кавычек, например, так:
echo ‘<a href=»/static/link» title=»Yeah yeah!»>Link name</a>’;
echo «<a href=’$link’ title=’$linktitle’>$linkname</a>»;
Текст, который входит в атрибуты, должен обрабатываться esc_attr(), чтобы одинарные или двойные кавычки не заканчивали значение атрибута, не вызывали проблем с HTML-валидацией и не вызывали проблем безопасности.

Отступы
Отступы должны всегда отражать логическую структуру. Используйте настоящие табуляции, а не пробелы, так как это обеспечивает наибольшую гибкость для клиентов.
Исключение: если у вас есть блок кода, который будет более читабельным при выравнивании, используйте пробелы:
[tab]$foo   = ‘somevalue’;
[tab]$foo2  = ‘somevalue2’;
[tab]$foo34 = ‘somevalue3’;
[tab]$foo5  = ‘somevalue4’;
Для ассоциативных массивов значения должны начинаться с новой строки. Обратите внимание на запятую после последнего элемента массива: это рекомендуется, поскольку так легче менять порядок элементов в массиве и добавлять новые элементы.
$my_array = array(
[tab]’foo’   => ‘somevalue’,
[tab]’foo2′  => ‘somevalue2’,
[tab]’foo3′  => ‘somevalue3’,
[tab]’foo34′ => ‘somevalue3’,
);
Эмпирическое правило: табуляции должны использоваться в начале строки для формирования отступа, в то время как пробелы могут использоваться в середине строки для выравнивания.

Стиль фигурных скобок
Фигурные скобки используются для всех блоков в стиле, показанном здесь:

if ( condition ) {
   action1();
   action2();
} elseif ( condition2 && condition3 ) {
   action3();
   action4();
} else {
   defaultaction();
}
Кроме того, если у вас есть действительно длинный блок, рассмотрите возможность его разбиения на два или больше коротких блоков или функций. Если вы считаете, что присутствие такого длинного блока неизбежно, поместите, пожалуйста, краткий комментарий в конце, чтобы люди могли быстро определить окончание блока — обычно это правило подходит для блоков длиннее приблизительно 35 строк, но любой код, который не является интуитивно понятным, может быть прокомментирован.
Фигурные скобки должны использоваться всегда, даже когда они не являются обязательными:
if ( condition ) {
   action0();
}
if ( condition ) {
   action1();
} elseif ( condition2 ) {
   action2a();
   action2b();
}
foreach ( $items as $item ) {
   process_item( $item );
}
Обратите внимание, что требование использования скобок просто означает, что запрещены управляющие inline-конструкции, состоящие из одной инструкции. Вы можете свободно использовать альтернативный синтаксис для управляющих конструкций (например, if/endif, while/endwhile) — особенно в ваших шаблонах, где PHP-код встраивается в HTML, например:
<?php if ( have_posts() ) : ?>
   <div class=»hfeed»>
       <?php while ( have_posts() ) : the_post(); ?>
           <article id=»post-<?php the_ID() ?>» class=»<?php post_class() ?>»>
               <!— … —>
           </article>
       <?php endwhile; ?>
   </div>
<?php endif; ?>

Запрет на сокращенные PHP-теги
Важно: никогда не используйте сокращенные открывающие PHP-теги. Всегда используйте полные PHP-теги.
Правильно:
<?php … ?>
<?php echo $var; ?>

Неправильно:
<? … ?>
<?= $var ?>

Удаление конечных пробелов
Удаляйте конечные пробелы в конце каждой строки кода. Желательно опускать закрывающий PHP-тег в конце файла. Если вы его все же используете, убедитесь, что вы удалите лишние пробелы в конце файла.

Использование пробелов
Всегда ставьте пробелы после запятых и по обе стороны логических операторов, сравнений, строк и операторов присваивания.
x == 23
foo && bar
! foo
array( 1, 2, 3 )
$baz . ‘-5’
$term .= ‘X’

Ставьте пробелы по обе стороны открывающих и закрывающих скобок блоков if, elseif, foreach, for, switch.
foreach ( $foo as $bar ) { …
Определение функции:
function my_function( $param1 = ‘foo’, $param2 = ‘bar’ ) { …
Вызов функции:
my_function( $param1, func_param( $param2 ) );
Выполнение логических сравнений:
if ( ! $foo ) { …

Приведение типов:
foreach ( (array) $foo as $bar ) { …
$foo = (boolean) $bar;

При обращении к элементам массива ставьте пробелы вокруг индекса только если он является переменной, например:
$x = $foo[‘bar’]; // правильно
$x = $foo[ ‘bar’ ]; // неправильно
$x = $foo[0]; // правильно
$x = $foo[ 0 ]; // неправильно
$x = $foo[ $bar ]; // правильно
$x = $foo[$bar]; // неправильно

Форматирование SQL-предложений

При форматировании SQL-предложений вы можете разбивать их на несколько строк и использовать отступы, если они достаточно сложные. Хотя большинство предложений хорошо работают и в виде одной строки. Всегда используйте прописные буквы для SQL-частей предложений, таких как UPDATE или WHERE.
В функции, которые обновляют базу данных, параметры должны передаваться после экранирования спецсимволов. Экранирование должно быть сделано как можно ближе к запросу, предпочтительно с помощью $wpdb->prepare().
$wpdb->prepare() — это метод, который управляет экранированием спецсимволов, заключением строк в кавычки и фильтрацией целочисленных параметров для SQL-запросов. Он использует подмножество стиля форматирования sprintf(). Пример :
$var = «dangerous'»; // данные, которые могут как нуждаться в экранировании, так и нет
$id = some_foo_number(); // ожидается целое число, но не обязательно
$wpdb->query( $wpdb->prepare( «UPDATE $wpdb->posts SET post_title = %s WHERE ID = %d», $var, $id ) );
%s используется для обозначения строкового значения и %d используется для целочисленных значений. Обратите внимание, что они не заключаются в кавычки! $wpdb->prepare() будет заботиться об экранировании спецсимволов и заключении строк в кавычки за нас. Преимущество этого заключается в том, что мы не должны беспокоиться о ручном использовании esc_sql(), и в том, что с первого взгляда видно, выполнено экранирование или нет, потому что оно делается непосредственно перед запросом.

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

Соглашение о выборе имен
Используйте строчные буквы в именах переменных, действий и функций (никогда не используйте camelCase-нотацию). Разделяйте слова с помощью знака подчеркивания. Не сокращайте имена переменных без необходимости; пусть код будет понятным и самодокументированным.
function some_name( $some_variable ) { […] }
Имена классов должны образовываться из слов, начинающихся с прописной буквы и разделенных символами подчеркивания. Все сокращения должны быть в верхнем регистре.
class Walker_Category extends Walker { […] }
class WP_HTTP { […] }
Имена констант должны быть в верхнем регистре со знаками подчеркиваниями, разделяющими слова:
define( ‘DOING_AJAX’, true );
Имена файлов должны описывать содержание и состоять из строчных букв. Слова должны разделяться дефисами.
my-plugin-name.php
Имена файлов, содержащих классы, должны образовываться на основе имени класса с префиксом class-, знаки подчеркивания в имени класса должны заменяться на дефисы, например WP_Error становится:

class-wp-error.php

Эти стандарты именования файлов распространяются на все имеющиеся и новые файлы с классами. Исключение составляют три файла, которые содержат код, входящий в BackPress: class.wp-dependencies.php, class.wp-scripts.php, class.wp-styles.php. Эти файлы начинаются с префикса class., содержащего точку, а не дефис.
Файлы, содержащие теги шаблонов в wp-includes должны иметь -template в конце имени, чтобы их содержание было очевидно.
general-template.php

Осмысленные значения аргументов функций, играющих роль флагов
При вызове функций отдавайте предпочтение строковым значениям, а не просто true и false.
// Неправильно
function eat( $what, $slowly = true ) {
…
}
eat( ‘mushrooms’ );
eat( ‘mushrooms’, true ); // Что значит true?
eat( ‘dogfood’, false ); // Что значит false?
Поскольку PHP не поддерживает именованные аргументы, значения флагов не имеют смысла, и каждый раз, когда мы сталкиваемся с вызовом функции, подобным приведенному выше, мы должны искать определение функции. Код можно сделать более читаемым, заменив логические значения осмысленными строковыми.
// Правильно
function eat( $what, $speed = ‘slowly’ ) {
…
}
eat( ‘mushrooms’ );
eat( ‘mushrooms’, ‘slowly’ );
eat( ‘dogfood’, ‘quickly’ );

Тернарный оператор
Тернарные операторы — это хорошо, но всегда проверяйте истинность утверждения, а не ложность. В противном случае, они становятся запутанными. (Исключением может быть использование ! empty(), поскольку проверка на ложь здесь более понятна.)
Например:
// (if statement is true) ? (do this) : (else, do this);
$musictype = ( ‘jazz’ == $music ) ? ‘cool’ : ‘blah’;
// (if field is not empty ) ? (do this) : (else, do this);

Умный код
В целом, читабельность важнее ума или краткости.
isset( $var ) || $var = some_function();
Хотя приведенная выше линия кода — умная, требуется время, чтобы ее понять, если вы не сталкивались с этим раньше. Поэтому лучше написать так:
if ( ! isset( $var ) ) {
   $var = some_function();
}