Базовые стандарты кодирования через PSR-1
Вчера я кратко рассказал об обосновании использования PSR по сравнению со стандартами кодирования WordPress, а также о том, когда и почему они оба. Но это не значит, что он не лишен путаницы, особенно если вы только начинаете с ними, верно?
Под этим я подразумеваю: скажем, вы работали со стандартами кодирования WordPress в течение многих лет (потому что я могу понять), и теперь есть целый новый набор правил и рекомендаций, которым нужно следовать. Но это не похоже на простое изменение некоторых пробелов и переименование файлов.
Есть и другие моменты, за которыми нужно следить, и каждый из них обозначен числом, совершенно буквально (PSR-1, PSR-2 и т. д.), указывающим, как что-то должно работать.
Итак, когда речь идет только об основных стандартах кодирования, изложенных в PSR-1, с какими проблемными областями мы можем столкнуться как разработчики WordPress?
Основные стандарты кодирования (и побочные эффекты)
У меня нет планов просматривать каждый из документов и перефразировать то, что мы уже можем узнать, просто прочитав их, но я думаю, что есть что сказать, если взять то, что многие из нас либо делают, либо испытывают, и посмотреть, как это может измениться в будущем. контекст WordPress.
Возьмите побочные эффекты из стандарта Basic Coding Standard (или PSR-1 ), например:
Файл ДОЛЖЕН объявлять новые символы (классы, функции, константы и т. д.) и не вызывать других побочных эффектов, или он ДОЛЖЕН выполнять логику с побочными эффектами, но НЕ ДОЛЖЕН делать и то, и другое.
Фраза «побочные эффекты» означает выполнение логики, не связанной напрямую с объявлением классов, функций, констант и т. д., просто из включения файла.
Лично я нахожу вторую фразу ключом к пониманию и максимальному предотвращению побочных эффектов в нашем коде. То есть все, что делают наши классы, должно быть автономным или быть связанным с чем-то, что могло быть каким-то образом внедрено.
Тем не менее, найти код, вызывающий побочный эффект, и очистить его не должно быть слишком сложно. На самом деле, я буду использовать себя в качестве примера.
Посмотрите на этот конкретный фрагмент кода :
Этот код взят прямо из уведомлений администратора Toggle. Конечно, это просто, и в репозитории есть примечание о том, как это изменить. Тем не менее, это демонстрирует суть, верно?
Какое решение? Это происходит в форме автозагрузки (которая также рассматривается в PSR-4 ). Так что, если бы я рефакторил его, чтобы он правильно следовал PSR-1? Тогда один из способов рефакторинга может выглядеть так :
Это отличный пример? Возможно нет. Но это больше, чем просто включение файлов. Включение этих файлов означает, что этот единственный файл вводит множество побочных эффектов.
Это означает, что один только этот файл отвечает за гораздо больше, чем просто эти четыре строки кода. Думайте об этом как о включении всего, что реализовано в других файлах. В этот момент она становится более сложной.
Так что возьмите эту идею и переместите ее в гораздо более крупную систему, и вы увидите, как и почему это может быть проблематично.
Конечно, есть и альтернативные способы. И это только один пример. Тоже самоуничижительный. Дело не столько в том, чтобы показать окончательный способ сделать это, сколько в том, чтобы начать закладывать мысли о том, как мы разрабатываем, планируем, создаем и включаем классы.
Что насчет просмотров?
Когда дело доходит до написания плагинов, я неравнодушен к тому, чтобы рассматривать то, что пользователи увидят, как представления. Но, похоже, здесь есть одна загвоздка: считается плохой практикой включать файлы, поскольку это приводит к побочным эффектам.
Поэтому мы не хотим выводить логику в наших классах, но мы также хотим отделить представление от бизнес-логики.
Что мы собираемся делать?
Изюминка… в том, что для этого мы собираемся использовать объектно-ориентированное программирование. Мы разработаем класс, который генерирует HTML с использованием шаблона PHP.
Это было подробно рассмотрено кем-то другим, и я настоятельно рекомендую прочитать этот конкретный пост, чтобы понять идею побочных эффектов, избежать их и максимально использовать надежные методы.
…И активы и связанные файлы?
Я знаю: идея уйти от побочных эффектов (не говоря уже о том, чтобы их идентифицировать) может поначалу показаться странной, особенно когда вы думаете о некоторых вещах, которые мы делали так долго.
И это может вызвать такие вопросы, как: неправильно ли включать файлы JavaScript или файлы CSS? Это, наверное, тема для отдельного поста. Помните, однако, что есть основные функции API, напрямую связанные с этим, и они могут быть частью класса, строго отвечающего за это.
Если цель класса состоит в том, чтобы делать именно это и только это, и он использует для этого функции API, то я бы сказал, что это, вероятно, нормально.
Но я пока отвлекся на это (и, возможно, это тема для комментариев или, опять же, отдельного поста).
Вместо этого старайтесь, чтобы ваши занятия были скудными и целеустремленными. Они должны делать то, что указано в PSR-1, и избегать таких вещей, как «[объявление] новых классов, функций, констант и т. д.». и «[выполнение] логики с побочными эффектами».