Стандарты кодирования WordPress: все вместе

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

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

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

С учетом сказанного давайте рассмотрим все, что мы рассмотрели при рассмотрении стандартов кодирования WordPress.

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

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

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

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

1. Соглашения об именах и аргументы функций

Соглашения об именах

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

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

Прямо из стандартов кодирования:

Не сокращайте имена переменных не обязательно; пусть код будет однозначным и самодокументируемым.

Но этот конкретный принцип стоит следовать независимо от того, где в коде вы работаете.

Аргументы функции

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

При вызове функций предпочитайте строковые значения только true и false .

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

2. Использование одинарных и двойных кавычек

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

Одинарные кавычки

Самый простой способ определить строку в PHP — это заключить ее в одинарные кавычки (то есть символ ‘).

Как и в большинстве языков программирования, существуют способы экранирования символов, чтобы вы могли записать строковый литерал. Например, если вы хотите написать: «Строки в PHP просты» как строку, то вы можете сделать это:

'String\'s in PHP are easy.'

Обратная косая черта будет инструктировать PHP писать одиночную кавычку, а не завершать фактическую строку. Второе, на что следует обратить внимание, это то, что если у вас есть переменная, она не будет заменена в кавычках.

Двойные кавычки

Двойные кавычки работают немного иначе в PHP. В частности:

Если строка заключена в двойные кавычки («), PHP будет интерпретировать больше escape-последовательностей для специальных символов.

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

Строки и WordPress

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

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

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

3. Отступы, пробелы и конечные пробелы

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

вдавливание

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

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

Обратите внимание, что Стандарты кодирования имеют правила для вкладок и пробелов:

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

Это особенно полезно в сообществе открытого исходного кода.

Космическое использование

Пробелы следует размещать в следующих местах:

После запятых
По обе стороны логических операторов (то есть, || , && и ! )
С обеих сторон операторов сравнения (то есть < , > , == , === и т. Д.)
По обе стороны от операторов присваивания (а именно = )
С обеих сторон открывающая и закрывающая скобки функций, условных выражений, циклов и т. Д.
Когда переменная передается как индекс массива, но не когда литеральное значение (например, строка или целое число)

Конечные пробелы

Это одно из самых простых соглашений. Честно говоря, велика вероятность того, что в вашей IDE или выбранном вами редакторе эта функция встроена или имеется плагин, который позволит вам автоматически это делать.

Если нет, вы сможете активировать возможность видеть вкладки, пробелы, возврат каретки и т. Д., Чтобы вы могли легко определить, где находятся пробелы в конце. И когда вы их видите, устраните их.

4. Стиль скобок, регулярные выражения и теги PHP

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

Brace Style

Вообще говоря, правила просты:

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

Это особенно распространено, если вы пришли из других языков стиля C; однако, так же, как в WordPress есть тонкие нюансы, которых нет в других языках, стоит выделить их здесь.

Регулярные выражения

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

Правила работы с регулярными выражениями в PHP в WordPress:

Используйте функции preg которые предлагает PHP
Не используйте переключатель \e , предлагаемый PHP — вместо этого используйте preg_replace_callback .

В частности, я рекомендую ознакомиться со следующими функциями:

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

Теги PHP

Существует очень простое правило использования тегов PHP в разработке WordPress:

Никогда не используйте сокращенные теги PHP

Это означает, что вы никогда не должны открывать файл или встроенный оператор PHP с помощью <? или с помощью <?= . Естественно, все встроенные операторы PHP должны заканчиваться закрывающим тегом ?> .

В дополнение к стандарту кодирования, который определен выше, я бы также добавил:

Избегайте добавления завершающего тега PHP в чистые файлы PHP.

Причиной этого было дословно упомянуто в соответствующей статье:

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

5. Тернарный оператор и условия йода

Когда речь заходит о написании кода на основе WordPress, Стандарты кодирования говорят, что мы должны стремиться к удобочитаемости:

В целом, удобочитаемость важнее, чем ум или краткость.

Некоторые разработчики считают, что троичный оператор немного расходится с этим конкретным принципом именно потому, что это еще один способ написания оператора if/else . Тем не менее, троичный оператор является жизнеспособным вариантом, когда речь идет о написании простых условных выражений, и это указано в стандартах кодирования WordPress.

Тернарный оператор

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

$uses_gasoline = ‘hybrid’ == $car_type ?
echo $uses_gasoline;

Важно отметить: троичный оператор проверяет истинность (а не ложь, очевидно).

Йода Условия

Условия Yoda относятся к обращению переменных к значениям, которые мы выполняем при написании кода WordPress. Мы это, в соответствии со стандартами кодирования, потому что:

В приведенном выше примере, если вы пропустите знак равенства (признайте, что это случается даже с самым опытным из нас), вы получите ошибку разбора, потому что вы не можете присвоить константу, такую как true . Если бы оператор был наоборот ( $the_force = true ) , присваивание было бы совершенно правильным, возвращая 1 , в результате чего оператор if оценивался бы как true , и вы могли бы некоторое время преследовать эту ошибку.

Конечно, это спорно, но она является частью стандарта , и вы будете видеть это использовать через основные WordPress, темы, плагины, статьи, и многое другое.

6. Запросы к базе данных и форматирование запросов SQL

Итак, короче говоря, если API не соответствует тому, что вам нужно, то $wpdb может быть вашим лучшим вариантом, но я рекомендую использовать его только в том случае, если вы исчерпали остальные параметры.

Запросы к базе данных

В WordPress есть ряд API, которые позволяют нам создавать собственные запросы без необходимости написания SQL. Некоторые из этих API включают в себя:

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

SQL-запросы

API не могут предсказать все случаи, когда нам нужно писать запросы к нашей базе данных. И в этих ситуациях WordPress предоставляет объект, который позволяет нам напрямую взаимодействовать с базой данных: $wpdb .

Это позволяет нам:

SELECT переменные, строки, столбцы и общие результаты
INSERT строки
UPDATE существующие строки

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

Но помните:

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

Вывод

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

Поэтому, если вам нравится эта конкретная стратегия или тип статьи, дайте мне знать, и, возможно, мы продолжим делать это для других серий; в противном случае, нет вреда, нет фола — я в порядке в любом случае

Несмотря на это, я надеюсь, что серия помогла объяснить ряд различных областей стандартов кодирования WordPress, которые вы либо ранее пропустили, неправильно поняли, либо до конца не поняли до прочтения этих статей.