Press WordPress Блог

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

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

Кавычки. Одинарные или двойные?
В WordPress есть принятый стандарт относительно того, где и при каких условиях использовать одинарные кавычки, а где двойные. Рассмотрим поподробнее.
Если вы присваиваете какое либо явное значение переменной, то используют двойные кавычки. Если присвоение происходит в самой строке – то одинарные. Исключение могут составлять вставки HTML кода при выводе, тут возможны два варианта

echo "<a href='/static/link' title='Yeah yeah!'>Link name</a>";
echo '<a href="/static/link" title="Yeah yeah!">Link name</a>';

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

Если текст, который будет передаваться как свойство или атрибут, следует предварительно обработать функцией attribute_escape() Это необходимо для того, чтобы «закрыть» незакрытые кавычками значения, и тем самым избежать неприятной ситуации. Как пример – использование XHTML или DHTML.

Отступы
Практически все разработчики настоятельно рекомендуют НЕ использовать пробелы. И если учитывать стандарты WordPress - ограничиваться только табуляцией. Дело в том, используя разные оболочки для кодирования можно столкнуться с такой неприятностью, как отсутствие читабельности вообще как таковой. Чего не должно быть. Код должен быть читаем в любом редакторе. И именно табуляция позволяет добиться минимальных потерь читаемости кода.
Исключения могут составлять блоки кода, в которых для отображения определенных участков кода табуляция будет лишней.

Скобки. Размещение скобок.
Для примера рассмотрим определенный кусок кода.

if ( condition ) {
action1();
action2();
} elseif ( condition2 && condition3 ) {
action3();
action4();
} else {
defaultaction();
}

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

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

Названия функций и переменных.
Всегда используйте логически понятные названия и только в нижнем регистре. Допускается использование символа «_» (нижний прочерк) и цифр. Зарезервированные названия переменных и функций использовать настоятельно не рекомендуют. Так же, как и переопределять их. Это может повлечь за собой ошибки в выполнении сценария. Стоит добавить из личного опыта, и о том, что стандарт WordPress не упоминает. Названия функций, если они несут какой-то определенный функционал, стоит начинать с set_ или get_. Так же стандарт WordPress не говорит о том, что в названиях функций все же стоит иногда использовать такую запись, как getMyFunctionName. То есть мы каждое логическое слово в названии функции отделяем символов верхнего регистра. Единственное условие в том, что если вы применяете подобный стиль в написании кода, то его следует придерживаться всегда.

Запросы к базе данных.
Тут довольно все просто. Зарезервированные слова, такие как SELECT, FROM, WHERE и т.д. рекомендуют писать в верхнем регистре.

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