На этом сайте мы проводим много времени, делясь информацией и обсуждая, как добиться определенных результатов с помощью WordPress. В конце концов, цель сайта — предоставить учебные материалы, то есть мы пытаемся дать практические советы о том, как создавать определенные вещи с помощью платформы.
Но разработка не строго о написании кода и создании вещей. Кроме того, речь идет о написании качества, поддерживаемом коде, рефакторинге и улучшении состояния наших проектов, а также о попытках оставить кодовую базу в лучшем состоянии, чем когда мы ее находили (или когда мы начали ее создавать).
Поэтому вместо того, чтобы сосредоточиться на том, как что-то создать или просмотреть какой-то конкретный код, давайте рассмотрим несколько практических советов по написанию качественного кода WordPress.
Стандарты кодирования WordPress
Прежде всего — и хотя мы много обсуждаем это — стоит повторяться снова и снова:
Следование стандартам кодирования WordPress — это одна из самых важных вещей, которую вы можете делать при написании своих тем, плагинов или приложений.
Для тех, кто незнаком, стандарты кодирования WordPress предоставляют правила того, как мы должны форматировать наш PHP на основе WordPress. Конечно, нет ничего, чтобы на самом деле обеспечить соблюдение правил — вы можете игнорировать их (и многие это делают), но это считается лучшим опытом для тех, кто серьезно относится к разработке проектов на основе WordPress, и его уважают те, кто активен в сообществе ,
Кроме того, следование стандартам кодирования означает, что у нас — вместе со всеми другими разработчиками, которые также это делают — будет похожий код. Фактически, одна из целей определенных стандартов кодирования состоит в том, чтобы код выглядел так, как будто он был написан одним разработчиком.
Еще одним преимуществом этого является то, что другим также легко вносить свой вклад в нашу кодовую базу. В конце концов, поскольку WordPress и его производные продукты являются открытым исходным кодом, другие могут захотеть прийти и внести свой вклад или в конечном итоге внести свой вклад, что даст им возможность легко читать наш код.
И наконец, это не обязательно призыв к действию, чтобы вернуться и реорганизовать все, что вы сделали. Сейчас самое подходящее время, чтобы начать следовать стандартам. Хорошие разработчики постоянно совершенствуются, поэтому начинать сейчас вполне приемлемо (даже если это в середине проекта).
Комментарии к коду
Одна из самых полезных вещей, которые вы можете сделать при написании кода, это оставлять полезные комментарии, которые точно объясняют, что именно вы пытаетесь сделать.
Естественно, комментарии могут жить на уровне класса, на уровне функций и на уровне строк. Они допустимы в PHP, HTML, JavaScript и CSS, поэтому на самом деле нет никаких оснований не включать их куда-либо.
Конечно, написание комментариев занимает немного больше времени, но помните, что если бы его было легко читать, его бы не называли кодом.
Подумайте об этом так: программисты печально известны тем, что возвращаются к своим предыдущим проектам и признают, насколько плох их код или как мы могли бы сделать что-то другое, если бы мы работали над этим проектом сейчас.
Если мы говорим это о нашем собственном коде, что должны думать другие, когда они видят наш код, особенно если они происходят из более опытного опыта?
Для более глубокого размышления о комментировании кода на стороне сервера и на стороне клиента обязательно ознакомьтесь с этой серией .
Упрощенные функции
Еще одна вещь, которую мы, разработчики, можем сделать, — это упростить наши функции. Хотя я понимаю, что это в некоторой степени субъективная область, я думаю, что стремление к меньшим, более сфокусированным функциям делает код более читабельным и в конечном итоге может помочь с тестируемостью (если вы заинтересованы в том, чтобы идти по этому пути).
Во-первых, нередко можно видеть функции, которые превышают 30, 40 или 50 строк. Проблема в том, что эти функции часто делают больше, чем одно.
Это проблематично, потому что:
- Это может затруднить диагностику проблемы при обнаружении ошибки
- Это может снизить читабельность кода, затрудняя присвоение функции уникального описательного имени.
- Это может затруднить написание конкретных модульных тестов, потому что функции не выполняют определенных задач.
Итак, с учетом сказанного, есть несколько практических советов, которым мы можем следовать, чтобы улучшить качество наших функций.
Оставайтесь сухими
Если вы обнаружите, что снова и снова пишете одну и ту же вещь в разных функциях, то это тот случай, когда вам нужно извлечь эту конкретную часть кода и переместить ее в свою собственную функцию, чтобы ее могли вызывать все места, которые это в настоящее время существует.
Поцелуй вверх
Если вы обнаружите, что ваш код либо сложно описать с помощью комментариев, либо трудно отследить во время его чтения, то, возможно, стоит сделать шаг назад и реорганизовать ваш код во что-то более простое.
В каждой ситуации это выглядит по-разному, но стремление к удобочитаемости, а не к сложности, зачастую является лучшей целью, а не просто заставить что-то работать.
Встать в очередь
Это, пожалуй, самый субъективный момент, я думаю, что это стоит затронуть, и это просто, что мы должны стремиться к тому, чтобы наши функции были небольшими с длиной в 20 строк, являющейся относительно прочной длиной, к которой нужно стремиться. Конечно, это может быть несколько сложной задачей, поскольку WordPress часто требует от нас создания больших массивов для передачи в качестве аргументов, но у вас есть идея: сохранять их небольшими, сфокусированными и обслуживаемыми.
Да, это приведет к появлению большего количества функций, но код будет легче читать и поддерживать, поскольку каждая функция имеет одну конкретную цель. Это означает, что вы можете назвать их с большей ясностью и более легко выполнять модульные тесты.
Вывод
Очевидно, что ни одно из вышеперечисленных не является жесткими правилами, которые необходимо соблюдать — это просто предложения о том, как улучшить качество кода, который мы пишем, который мы поддерживаем, и который мы вносим в работу других.
Прежде всего, я считаю, что мы должны стремиться к удобочитаемости и тестируемости. Сохранение этих двух целей на переднем крае нашей работы поможет привести все остальное на свое место.
Конечно, это не полный список — это далеко не так! Поэтому, пожалуйста, предложите свои предложения в комментариях!