В этой серии мы углубились в стандарты кодирования WordPress, чтобы рассказать о них, понять их и начать практически применять их в нашей повседневной работе.
Если вы просто присоединяетесь к этой серии, мы рассмотрели следующие темы:
- Соглашения об именах и аргументы функций
- Одинарные и двойные кавычки
- Отступы, использование пробелов и пробелы
В этой статье мы продолжим основываться на содержимом предыдущей статьи: в частности, мы рассмотрим стиль фигурных скобок, регулярные выражения и нюансы работы с тегами PHP в контексте создание тем WordPress, плагинов и приложений.
Почему стиль имеет значение
В этой серии статей одна и та же проблема, которую мы повторяли снова и снова, заключается в том, что стандарты кодирования помогают сделать код более читабельным, поддерживаемым и что в конечном итоге они должны выглядеть так, как будто один разработчик написал код.
Но одна из вещей, о которых мы на самом деле мало говорили, это то, почему стиль имеет значение. Однако сначала возникает вопрос: в чем разница между стилем и соглашениями по кодированию?
Честно говоря, я думаю, что некоторые скажут, что нет никакой разницы — на самом деле, они скажут, что они являются синонимами. Я не обязательно согласен Лично я всегда видел, как стандарты кодирования определяют стиль написанного кода. Стандарты кодирования — это соглашения, в соответствии с которыми мы разрабатываем код.
Brace Style
Итак, сказав это, давайте продолжим наш разговор об условных обозначениях кодирования, посмотрев, как стандарты кодирования WordPress определяют использование фигурных скобок.
Вообще говоря, правила просты:
- Однолинейные блоки могут опускать скобки
- Многострочные блоки всегда должны включать фигурные скобки
- Если у вас слишком много многострочных условных выражений, рассмотрите возможность разбиения условных выражений на их собственные функции, чтобы минимизировать блок
Эти принципы часто лучше всего демонстрируются в коде. Первые два просты:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
|
// Single Line conditional examples
if ( condition1 )
do_work();
if ( condition1 )
do_work();
else
dont_do_work();
// Multiline conditionals
if ( condition1 ) {
do_work();
do_more_work();
} else {
dont_do_work();
seriously_be_lazy();
}
// Single Line loops (true for do/while, while, for, and foreach)
while ( condition1 )
dont_stop_believing();
// Single Line loops (true for do/while, while, for, and foreach)
while ( condition1 ) {
dont_stop_believing();
hold_on_to_that_feeling();
}
|
Ничего страшно сложного, правда?
На самом деле, вы можете видеть, что я использовал методы в блоках выше. Вот что приводит нас к следующему принципу: если у вас слишком сложное тело в вашем условном выражении, это, вероятно, поможет изменить условное обозначение для облегчения восприятия.
Давайте посмотрим на пример.
Перед
В этом примере мы собираемся перебрать метаданные текущего пользователя, и, если метаключ текущего пользователя содержит подстроку «destroy:», мы удалим метаключ этого пользователя.
Обратите внимание, что в этом примере вся эта работа выполняется в условном, в цикле foreach , а затем в другом условном.
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
|
// If condition1 is true…
if ( condition1 ) {
// …then get the user meta data for the current user
foreach( get_user_meta( wp_get_current_user()->ID ) as $meta_key => $meta_value ) {
// If user has a destroy value set, delete it.
if( strstr( $meta_key, ‘destroy:’ ) ) {
delete_user_meta( wp_get_current_user()->ID, $meta_key );
}
}
}
|
Много вложенного кода, верно?
После
Есть множество способов, которыми это может быть реорганизовано. На самом деле, некоторые разработчики идут так далеко, что берут каждый блок и абстрагируют его в свой собственный метод — в этом нет ничего плохого.
Но чтобы продемонстрировать этот момент, мы собираемся предоставить только один уровень абстракции: мы собираемся взять цикл и внутреннее условное выражение, переместить его в функцию, которая принимает пользователя, а затем выполнить исходное действие.
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
|
// If condition1 is true…
if ( condition1 ) {
process_user( wp_get_current_user() );
}
function process_user( $user ) {
// Get the user meteta data for the current user
foreach ( get_user_meta( $user->ID ) as $meta_key => $meta_value ) {
// If user has a destroy value set, delete it.
if ( strstr( $meta_key, ‘destroy:’ ) ) {
delete_user_meta( $user->ID, $meta_key );
}
}
}
|
Как я уже сказал, это сравнительно простой пример, но суть остается: Перемещение большого блока кода в его собственную специализированную функцию может значительно улучшить рефакторинг условного выражения, чтобы его было легче читать.
Регулярные выражения
На этом этапе мы немного переключимся и поговорим о регулярных выражениях. Если вы не знакомы с регулярными выражениями, просто знайте, что это эффективные способы сопоставления символов или строк. Вы можете прочитать о них больше в Википедии .
В какой-то момент вашей карьеры в WordPress вы, вероятно, столкнетесь с ними — либо в основном исходном коде, либо в коде темы или плагина, либо даже в том, что вам понадобится выполнить действие в вашем собственном проекте.
К счастью, PHP предлагает некоторые действительно простые, действительно мощные функции для использования регулярных выражений в вашем коде; однако, есть правильное и неправильное их использование, когда дело доходит до работы с ними в WordPress.
Вот общие правила:
- Используйте функции
pregкоторые предлагает PHP - Не используйте переключатель
\e, предлагаемый PHP — вместо этого используйтеpreg_replace_callback.
Для тех, кому любопытно, есть ряд доступных функций.
Например, я рекомендую ознакомиться с:
Наконец, preg_replace_callback — это способ вызова функции, когда регулярное выражение нашло совпадение.
Очевидно, что правила для регулярных выражений в WordPress просты — это скорее вопрос знания функций, которые вы должны использовать, и того, что вы не должны использовать, и того, как использовать их в своей повседневной работе.
Теги PHP
Последнее, что нужно осветить в этой статье, — это важность использования тегов PHP в файлах PHP, составляющих ваш проект. К счастью, для этой конкретной ситуации есть очень простое правило:
- Никогда не используйте сокращенные теги PHP
Прежде всего, это означает, что вы никогда не должны открывать файл или встроенный оператор PHP с помощью <? или с помощью <?= . Естественно, все встроенные операторы PHP по-прежнему должны заканчиваться закрывающим тегом ?> .
Теперь эта следующая тема немного отклоняется от стандартов кодирования, по крайней мере, на момент написания этой статьи становится все более распространенной практикой оставлять закрывающий тег в нижней части файла, если и только если первая строка рассматриваемого файла является открывающим <?php .
В частности, это чаще встречается в контексте плагинов, чем в темах, и вот почему: PHP — это способ, которым код на стороне сервера может быть встроен во внешнюю разметку. Таким образом, он требует как открывающий тег, так и закрывающий тег, чтобы интерпретатор знал, как анализировать код.
Но если вы пишете плагин или файл приложения на 100% PHP, тогда нет необходимости добавлять завершающий тег в конце файла. Синтаксический анализатор сможет обнаружить его сам, и, если вы включите завершающий тег, у вас может остаться пробел в конце файла, что может вызвать всевозможные проблемы, когда придет время активировать плагин.
Поэтому в дополнение к стандарту кодирования, который определен выше, я бы также добавил:
- Избегайте добавления завершающего тега PHP в чистые файлы PHP.
Вывод
По мере того, как мы приближаемся к последнему этапу изучения стандартов кодирования WordPress, мы начнем фокусироваться на более мелких вещах, таких как троичные операторы и условия Yoda; однако мы также рассмотрим тонкости выполнения встроенных SQL-запросов и важные правила, связанные с этим.
Если вы еще не ознакомились с сериалом, сейчас самое время перечитать то, что мы рассмотрели, поскольку это будет влиять на то, к чему мы движемся в следующем наборе статей.