Основні стандарти кодування через PSR-1
Учора я коротко поговорив про обґрунтування використання PSR проти стандартів кодування WordPress, а також про те, коли й чому. Але це не означає, що він не позбавлений моментів плутанини, особливо якщо ви тільки починаєте з ними, чи не так?
Під цим я маю на увазі: скажімо, ви працювали зі стандартами кодування WordPress роками (тому що я можу це зрозуміти), і тепер є цілий новий набір правил і вказівок, яких слід дотримуватися. Але це не схоже на просте змінення пробілу та перейменування файлів.
Існують інші пункти, яких слід дотримуватися, і кожен описується буквально цифрами (PSR-1, PSR-2 і так далі), як щось має працювати.
Отже, якщо мова йде лише про базові стандарти кодування, викладені в PSR-1, з якими проблемними областями ми можемо зіткнутися як розробники WordPress?
Основні стандарти кодування (і побічні ефекти)
Я не планую переглядати кожен із документів і повторювати те, що ми вже можемо дізнатися, просто прочитавши їх, але я думаю, що є що сказати про те, що багато хто з нас або робить, або переживає, і дивиться, як це може змінитися протягом контексті WordPress.
Візьміть побічні ефекти з Базового стандарту кодування (або PSR-1 ), наприклад:
Файл ПОВИНЕН декларувати нові символи (класи, функції, константи тощо) і не викликати жодних інших побічних ефектів, або СЛІД виконувати логіку з побічними ефектами, але НЕ ПОВИНЕН робити те й інше.
Фраза «побічні ефекти» означає виконання логіки, не пов’язаної безпосередньо з оголошенням класів, функцій, констант тощо, лише включення файлу.
Особисто я вважаю другу фразу ключем до розуміння та уникнення побічних ефектів у нашому коді, наскільки це можливо. Тобто все, що роблять наші класи, має бути самодостатнім або бути пов’язаним із чимось, що могло бути введено якимось чином.
Незважаючи на це, знайти код, який створює побічний ефект, і очистити його не повинно бути надто важко. Насправді я наведу себе як приклад.
Подивіться на цей конкретний фрагмент коду :
<?php
namespace TAN;
use TANAdmin;
include_once( 'admin/class-toggle-admin-notices-node.php' );
include_once( 'admin/interfaces/interface-asset.php' );
include_once( 'admin/class-javascript-assets.php' );
add_action( 'plugins_loaded', __NAMESPACE__. 'tan_start' );
/**
* Initializes the JavaScript loader and the Administration Bar Node for
* rendering the option to toggle admin notices.
*/
function tan_start() {
// Code removed for brevity.
}
Цей код прямо з Toggle Admin Notices. Звичайно, це просто, і в репозиторії показано примітку про те, як це змінити. Тим не менш, це демонструє суть, чи не так?
Яке рішення? Це відбувається у формі автозавантаження (яке також описано в PSR-4 ). То що, якби я переробив його, щоб він відповідав PSR-1 належним чином? Тоді один із способів рефакторингу може виглядати так :
<?php
namespace TAN;
use TANAdmin;
include_once 'inc/autoload.php';
add_action( 'plugins_loaded', __NAMESPACE__. 'tan_start' );
/**
* Initializes the JavaScript loader and the Administration Bar Node for
* rendering the option to toggle admin notices.
*/
function tan_start() {
// Code removed for brevity.
}
Це чудовий приклад? Напевно ні. Але це більше, ніж просто включення файлів. Включаючи ці файли, цей один файл створює різноманітні побічні ефекти.
Це означає, що лише цей один файл відповідає за набагато більше, ніж просто чотири рядки коду. Думайте про це як про включення всього, що реалізують інші файли. У цей момент це стає складнішим.
Тож візьміть цю ідею та перемістіть її в набагато більшу систему, і ви побачите, як і чому це буде проблематично.
Звичайно, існують і альтернативні шляхи. І це лише один приклад. Також самоприниження. Суть полягає не стільки в тому, щоб показати остаточний спосіб зробити це, скільки в тому, щоб почати засівати думки про те, як ми розробляємо, плануємо, створюємо та включаємо класи.
Що щодо переглядів?
Коли справа доходить до написання плагінів, я прихильно ставлюся до того, що користувачі бачитимуть як перегляди. Але, здається, тут є підступ: додавати файли вважається поганою практикою, оскільки це створює побічні ефекти.
Тому ми не хочемо виводити логіку в наших класах, але ми також хочемо відокремити презентацію від бізнес-логіки.
Що нам робити?
Поворот … полягає в тому, що ми збираємося використовувати для цього об’єктно-орієнтоване програмування. Ми розробимо клас, який генерує HTML за допомогою шаблону PHP.
Це було докладно розглянуто кимось іншим, і я настійно рекомендую прочитати цю конкретну публікацію, щоб зрозуміти ідею побічних ефектів, уникати їх і включати надійні практики, наскільки це можливо.
…А активи та пов’язані файли?
Я знаю: ідея відмовитися від побічних ефектів (не кажучи вже про їх ідентифікацію) спочатку може бути дивною, особливо коли ви думаєте про певні речі, які ми робили так довго.
І це може викликати запитання на зразок: чи неправильно включати файли JavaScript або файли CSS? Це, мабуть, тема для окремої публікації. Однак пам’ятайте, що існують основні функції API, безпосередньо пов’язані з цим, і вони можуть бути частиною класу, який суворо відповідає за це.
Якщо мета класу полягає в тому, щоб робити саме це і тільки це, і він використовує для цього функції API, то я б сказав, що це нормально.
Але я поки що відволікся від цього (і, можливо, це тема для коментарів або, знову ж таки, інший пост).
Натомість тримайте свої заняття щадними та цілеспрямованими. Вони повинні діяти відповідно до PSR-1 і уникати таких дій, як «[оголошення] нових класів, функцій, констант тощо». і «[виконання] логіки з побічними ефектами».