Периодически мне приходится работать и разбираться в чужом коде и могу сказать, что иногда попадается такое, что тратишь огромное количество времени лишь на то, чтобы это было хоть как-то читаемо. Поэтому я хотел бы немного поговорить о некоторых рекомендациях того, как должен выглядеть ваш код.
Прежде всего, не будет лишним упомянуть, что названия переменных и классов должны быть существительными, функции – глаголами и все они должны быть максимально простыми но при этом понятными в плане того, какой цели они служат.
Теперь более конкретно.
Названия классов в WordPress должны следовать следующим правилами:
_
.Несложно же? Примеры: WC_Order
, WC_Truemisha_Gateway
, WP_Object_Cache
, My_Class
.
Только маленькие буквы, слова разделены знаком подчеркивания _
.
Например: function add_your_shipping_method()
или $default_image_sizes
.
При создании файлов для, скажем, своей темы или плагина, не забывайте, что:
-
.class-
, примеры: WC_Order
должен быть class-wc-order.php
, WC_Truemisha_Gateway
должен быть class-wc-truemisha-gateway.php
.Когда мы говорим о передаче параметров в функции, нужно помнить, что название функции должно обозначать действие, которые она выполняет, а названия её аргументов – что и как конкретно она делает. Особенно это может касаться логических переменных. Ок, давайте пример.
Плохой пример:
// какой-то класс управления файлом class Local_File_Manager { public function manage_file( $filename, true ) { if ( true ) { // открываем файл } else { // удаляем файл } } } // не особо понятно, верно ведь? $file_manager = new Local_File_Manager(); $file_manager->manage_file( 'foo.txt', true );
Хороший пример:
class Local_File_Manager { public function open_file( $filename ) { // открываем файл } public function delete_file( $filename ) { // удаляем файл } } // а вот так уже понятней! $file_manager = new Local_File_Manager(); $file_manager->open_file( 'foo.txt' ); $file_manager->delete_file( 'foo.txt' );
В официальном руководстве WordPress рекомендуется использовать одинарные и двойные кавычки по ситуации, избегая их экранирования.
Я предпочитаю отдавать предпочтение одинарным кавычкам, например:
echo '<a href="' . site_url() . '">Главная</a>'; // а не "<a href='" . site_url() . "'> ...
Даже когда нужно передавать переменные в строку:
echo '<a href="' . site_url() . '" title="' . esc_attr( $title ) . '">Ссылка</a>';
Потому что:
А вот это боль! 😾
Прежде всего, забудьте про отступы пробелами!
if( условие ) { echo 'hello'; // перед echo стоит таб }
Когда вы копируете код с некоторых сайтов, или же работаете с чужим кодом, там часто можно встретить пробелы и это так раздражает! В таких ситуациях в своём редакторе кода я выделяю весь код со стрёмными отступами и использую комбинацию Shift + Tab.
Исключение – пробелы в середине строки для удобства чтения:
$foo = 'какое-то значение'; $foo2 = 'какое-то значение2'; $foo34 = 'какое-то значение3'; $foo5 = 'какое-то значение4';
В ассоциативных массивах, состоящих более, чем из одного элемента, каждый элемент должен начинаться с новой строчки:
$args = array( 'post_type' => 'page', 'post_author' => 123, 'post_status' => 'publish', );
Также есть рекомендация добавлять запятую после последнего элемента массива, это позволяет легче добавлять новые элементы или менять их местами.
или, если один элемент:
$args = array( 'post_type' => 'page' );
Есть некоторые рекомендации, где следует добавлять пробелы и, поверьте, после этого ваш код будет выглядеть очень красиво!
||
, &&
, и !
),if ( ! $echo ) { ...
<
, >
, ==
, ===
, и т д.)=
)if ( $terms ) { foreach ( $terms as $term ) { ...
$arr[ $x ] = 'foo'; // пробелы только тут $arr[0] = 'bar'; $arr['foo'] = 'bar';
При использовании кода PHP вместе с блоком HTML, открывающий и закрывающий теги <?php
и ?>
должны быть ЛИБО на одной строке:
<?php while( have_posts() ) : the_post(); ?>
ЛИБО единственными на строке:
function foo() { ?> <div> <?php echo bar( $baz, $bat ); ?> </div> <?php }
Все аргументы функции при её вызове либо должны все находиться на одной строке, либо каждый аргумент – на новой строке, пример:
$url = add_query_arg( array( 'param_1' => 'value_1', 'param_2' => 'val2', ), admin_url() );
Тут легко – используем всегда, даже если они не обязательны.
if( условие ) { действие }
Но это не значит, что мы не можем использовать альтернативный синтаксис записи условий и циклов if/endif
, while/endwhile
, наоборот он рекомендуется, если у вас в коде присутствует вывод HTML.
<?php while ( have_posts() ) : the_post(); ?> <article id="post-<?php the_ID() ?>" class="<?php post_class() ?>"> <!-- ... --> </article> <?php endwhile; ?>
Как раз в том случае, если мы будем использовать альтерантивный синтаксис условий (с двоеточием), то в случае else if
, мы получим фатальную ошибку, поэтому – только elseif
, всегда.
Для тех, кто не знаком, тернарный оператор упрощает запись условий if / else
. Лучше всего показать на примере:
$is_electric = null; if ( 'tesla' == $car_name ) { $is_electric = true; } else { $is_electric = false; }
Зацените, как сильно упрощается условие:
$is_electric = 'tesla' == $car_name ? true : false;
Тут одно правило – тернарным оператором нужно проверять только правдивое утверждение, за исключением проверок ! empty()
.
Если вы взгляните на код чуть выше, то заметите, как «условия я записывал», а именно – сначала значение, а потом переменная. Почему так?
Условие Йоды | Обычное условие |
---|---|
if ( 'tesla' == $car_name ) { | if ( $car_name == 'tesla' ) { |
if( false !== $echo ) { | if( $echo !== false ) { |
Например, если в коде выше мы случайно пропустим один знак =
, что иногда с вами случалось, со мной уж точно, то вы получите parse error, потому что вы не можете делать присвоение к константам, если же наша запись была в формате ( $car_name = 'tesla' )
, то всё было бы ок, оно возвращало бы true
, и вы бы пытались какое-то время понять, что же в коде не так.
Условия Йоды применяются к операторам ==
, !=
, ===
, and !==
, но не <
, >
, <=
или >=
.
По возможности всегда используем операторы тождественного сравнения, пример:
if ( 0 === strpos( 'WordPress', 'foo' ) ) { echo 'Привет WordPress!'; }
Признаюсь вам честно, пока что я фейлю здесь и делаю не правильно, например мне очень нравится такая запись:
if( $post_meta = get_post_meta( get_the_ID(), 'meta_key', true ) ) { // делаем что-то с $post_meta }
Но такую запись не нужно использовать, правильно её переделать вот так:
$post_meta = get_post_meta( get_the_ID(), 'meta_key', true ); if( $post_meta ) { // делаем что-то с $post_meta }
Обещаю исправиться! А вам рекомендую сразу делать правильно 👆
Никогда не жертвуйте удобством читаемости кода ради того, чтобы он выглядел «по-умному», например если вам хочется сделать такую запись isset( $var ) || $var = some_function()
, то вовремя остановитесь, и сделайте по-нормальному:
if ( ! isset( $var ) ) { $var = some_function(); }
Массивы пишем вместе со словом array()
, не ленимся array( 5, 10, 'привет' )
. Не надо их делать как в JavaScript с квадратными скобками.
Что бы кто вам не говорил, а если сомневаетесь, попробуйте найти в ядре WordPress хоть одну запись массива с квадратными скобками.
Только <?php
и ?>
, а не <?
и ?>
.
А также <?php echo $var; ?>
вместо <?= $var ?>
Списочек:
eval()
и create_function()
из-за их небезопасности,goto
,@
,extract()
Вообще, про хуки (фильтры и действия) у меня есть отдельный подробный урок.
Бывает, что название хука статично и является строкой: do_action( 'wp_head' )
, а иногда может состоять из переменных, например:
do_action( "woocommerce_after_edit_address_form_{$load_address}" );
Короче говоря, если название хука содержит переменные, то помещаем его в двойные кавычки, а переменные внутри – в фигурные скобки.
Они появились в версии PHP 7.3 и благодаря им мы можем очень классно записывать сниппеты к хукам WordPress, лишний раз не раздумывая над именем функции к хуку, например:
add_action( 'woocommerce_single_product_summary', function() { // выводим тут что-то }, 25 );
Вообще такая запись это ок, но:
Последнее, но пожалуй, самое важное.
$wpdb->prepare()
, подробнее тут.Чтобы оставить комментарий, пожалуйста, зарегистрируйтесь или войдите.
Спасибо! Очень годный гайд!
🔥🌪⚡️
А чем PSR не угодил? https://www.php-fig.org/psr/psr-12/
Да ничем,
но возможно вы найдёте ответ на свой вопрос тут в комментариях например https://wptavern.com/proposal-to-update-the-wordpress-coding-standards-for-modern-php#comments