Стандарты кодирования для WordPress [Guide]

Причина, по которой у нас вообще есть стандарты кодирования (не только для WordPress), заключается в создании привычной среды для программистов, работающих над проектом. WordPress, в частности, охватывает широкий спектр продуктов. Начиная с самого ядра и заканчивая темами и плагинами, есть на что посмотреть – и многое нужно перепутать.

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

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

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

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

Больше на Hongkiat.com:
Некоторые заметки о стандартах
Стандарты не определяют правильное и неправильное. Вы можете не согласиться с правилом, например брекеты всегда следует использоватьдаже если они не нужны. Цель стандартов кодирования WordPress – не решить, правы вы или нет, а решить, как это сделать в WordPress.

Стандарты не подлежат обсуждению. Использование стандартов – это не то место, где можно выступить против стиля отступов, который вам не нравится. Если что-то есть в стандартах кодирования, делайте так. Разработчики WordPress будут любить вас за это! Тем не менее, если вы не согласны с чем-то, поднимите свой голос и дайте людям знать. Всегда можно сделать что-то лучше, но вы должны изменить свой стиль кодирования, только если это допускают стандарты.

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

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

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

Прямо сейчас WordPress имеет четыре руководствапо одному на каждый используемый основной язык: PHP, HTML, Javascript и CSS. Они составляют часть большего объема знаний, Справочник основного участника, Прохождение всего заняло бы некоторое время, поэтому я выделил некоторые фрагменты из четырех языков, которые я часто вижу, как люди ошибаются.
PHP
PHP является основным языком WordPress и является довольно свободно типизированным языком, что делает его зрелым для регулирования.
Brace Styles
Стартовые скобки всегда должны быть в конце строк. Связанные операторы должны быть помещены в ту же строку, что и предыдущая закрывающая скобка. Это лучше всего продемонстрировать на примере кода:
if (условие) {
// Сделай что-нибудь
} elseif (условие) {
// Сделай что-нибудь
} еще {
// Сделай что-нибудь
}
Щедрое использование пространства
Я не фанат раздавленного кода (у меня плохое зрение), поэтому я особенно люблю его применять. Поставляйте пробелы после запятых и по обе стороны от логических операторов, операторов сравнения, строк и присваивания, после операторов if, elseif, for, foreach и switch и так далее.

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

Довольно запутанным исключением из этого правила являются массивы, в которых ключ массива является переменной, в этом случае используется пробел. Этот пример должен прояснить это:
function my_function ($ complete_array = null, $ key_1 = 4, $ key_2 = ‘bar’) {
if (null == $ complete_array) {
$ final_array = $ complete_array;
} еще {
$ key_1 = (целое число) $ key_1;
$ final_array[0] = ‘это’;
$ final_array[ $key_1 ] = ‘есть’;
$ final_array[ $key_2 ] = ‘an’;
$ final_array[‘last’] = ‘пример’;
}
вернуть $ final_array;
}
Соглашения об именах
К этому может быть сложно привыкнуть, особенно если вы приехали из разных сред. В двух словах:

• Все имена переменных должны быть в нижнем регистре, слова разделены подчеркиванием
• Имена классов должны использовать заглавные слова, разделенные подчеркиванием. Акронимы должны быть заглавными
• Константы должны быть в верхнем регистре, подчеркнуты подчеркиванием
• Все имена файлов должны быть в нижнем регистре, разделены тире

Йода Условия
Запись условий, отличных от тех, к которым вы привыкли, предотвратит ошибки синтаксического анализа. Это выглядит немного странно, но это лучший код.
if (‘Daniel’ === $ name) {
echo ‘Напиши статью, ты будешь’;
}
HTML
У HTML не так много связанных правил, я мог бы придумать довольно много, чтобы сделать его более модульным. При написании HTML нужно знать только пять правил:

1. Ваш код должен соответствовать W3C валидатор,
2. Самозакрывающиеся HTML-теги должны иметь ровно один пробел перед косой чертой (это я лично ненавижу, но это спецификация W3C, а не просто любимая мозоль WordPress)
3. Все атрибуты и теги должны быть строчными. Единственное исключение – когда значения атрибутов предназначены для потребления человеком, и в этом случае их следует вводить естественным образом.
4. Все атрибуты должны иметь значение и должны заключаться в кавычки не является правильным)
5. Отступы должны быть достигнуты с помощью вкладок и должны следовать логической структуре.

CSS
CSS – еще один свободно типизированный язык, поэтому здесь также предстоит проделать большую работу. Несмотря на это, стандарты довольно просты для программистов.
Селекторы
Селекторы должны быть настолько квалифицированными, насколько это необходимо, быть удобочитаемыми, иметь строчные буквы со словами, разделенными черточками, а селекторы атрибутов должны использовать двойные кавычки. Вот краткий пример:
вход[type=”text”],
вход[type=”password”],
.name-field {
фон: # f1f1f1;
}
Заказ недвижимости
Стандарты признают необходимость некоторого личного пространства здесь, поскольку они не предписывают определенный порядок для правил CSS. Они говорят, что вы должны следовать смысловой структуре, которая имеет смысл. Группируйте свойства по их отношениям или группируйте их в алфавитном порядке, просто не записывайте их случайным образом.

Самая большая причина для случайности – «о, мне также нужно добавить поле», а затем приступить к его добавлению к нижней части. Возьмите лишние 0,3 секунды и добавьте правило в логическое место.

• дисплей
• позиционирование
• Модель коробки
• Цвета и типография
• Другой

.profile-modal {
дисплей: блок;
позиция: абсолютная;
Слева направо: 100px;
топ: 90px;
фон: # ff9900;
цвет: #fff;
}
Форматирование значения
Это одно место, где я особенно ненавижу видеть несоответствия. Если вы не следуете рекомендациям, это все же лучше, чем иногда видеть пробел перед значением; иногда используя стенографию, иногда нет; иногда используя единицы на 0 значениях, иногда нет и т. д.

Форматирование значений довольно сложное, но оно приходит с некоторой практикой. Посмотрите на точное руководство в кодекс для форматирования ваших значений.
Javascript
По моему опыту, Javascript наиболее подвержен повсеместному распространению. Несмотря на то, что многие разработчики знают значительное количество Javascript, он изучался постепенно, как запоминание HTML, CSS и PHP. Когда вы только начинаете работать с новым языком, вы совершаете гораздо больше ошибок, и если эти ошибки не приводят к фатальным ошибкам, они могут укорениться в вас.

Во многих случаях стандарты ссылаются на ограничение линии или указание «если линия не слишком длинная». Это относится к Руководство по стилю jQuery который накладывает ограничение в 100 символов на строки. Руководство по WordPress основано на руководстве по jQuery, поэтому неплохо прочитать его.
Точка с запятой
Это простейшее правило, но оно часто игнорируется. Никогда, никогда не опускайте точку с запятой только потому, что ваш код будет работать без него. Это просто небрежно.
Отступ
Вкладки всегда должны использоваться для отступа. Также следует сделать отступ для содержимого замыкания, даже если содержимое всего файла содержится в одном. Я не уверен, почему, но незапятнанное закрытие верхнего уровня дало мне толчок еще до того, как я прочитал стандарты
Ломать линии
При разрыве длинных строк всегда разрывайте строку после оператора, не оставляйте переменную висящей вокруг. С первого взгляда становится очевидным, что линия разорвана, и вы не забыли точку с запятой.

Также, если условие длинное, разбейте его на несколько строк и добавьте перед ним дополнительную вкладку. Это выглядит очень странно для моих глаз, но разделение, которое оно добавляет между состоянием и телом, очень заметно.
if (firstCondition () && secondCondition () &&
thirdCondition ()) {
var html = ‘Эта строка состоит из слов’ + n + ‘, поэтому она должна быть разбита после’ +
«оператор»;
}
jQuery Iteration
В соответствии со стандартами итерация jQuery (jQuery.each ()) должна использоваться только для объектов jQuery. Вы должны использовать циклы basic для, for / in, while в Javascript для итерации по другим коллекциям.

Вывод

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

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

Вы ненавидите элемент стандартов кодирования, как вы думаете, что-то должно быть добавлено? Дайте нам знать об этом в комментариях!