Щоразу, коли я працюю над проектом, я часто встановлюю WordPress у режим налагодження, і я люблю писати повідомлення в журнал помилок, які я можу легко переглядати, відстежувати та слідкувати, коли я працюю над проектом.
Коли я роблю це, є два способи (і це залежить лише від проекту):
- Я буду використовувати таку бібліотеку, як Monolog ,
- Я буду використовувати власну просту функцію журналу.
У цій публікації я збираюся висвітлити останній. Тобто я збираюся поділитися тим, як я пишу повідомлення в журнал налагодження WordPress, а потім розповім про деякі речі, на які вам може знадобитися звернути увагу, коли ви робите те саме.
Журнал налагодження WordPress
По-перше, важливо зазначити, що функція, якою я збираюся поділитися, зазвичай знаходиться в контексті базового класу.
Припустімо, у мене є AbstractSubscriber, який реалізують усі мої передплатники (наприклад, ScriptAssetSubscriber для реєстрації та постановки в чергу файлу JavaScript).
AbstractSubscriber включатиме цю функцію, щоб її могли викликати будь-які дочірні класи. Функція досить проста:
<?php
/**
* Prints a message to the debug file that can easily be called by any subclass.
*
* @param mixed $message an object, array, string, number, or other data to write to the debug log
* @param bool $shouldNotDie whether or not the The function should exit after writing to the log
*
*/
protected function log($message, $shouldNotDie = true)
{
error_log(print_r($message, true));
if ($shouldNotDie) {
exit;
}
}Але в цій функції є кілька речей, які можуть порушувати принцип або викликати помилки в інструментах якості коду.
Необов’язкові булеві аргументи
Кожного разу, коли функція приймає необов’язковий логічний аргумент, це може означати, що функція має більше ніж одну відповідальність (таким чином порушуючи принцип єдиної відповідальності ).
Причина, по якій це порушує вказаний принцип, полягає в тому, що це дає модулю більше ніж одну причину для змін.
Я спокійно дозволяю, щоб це було написано таким чином, оскільки я використовую його для налагодження, а не для робочих середовищ, і тому що бувають моменти, коли я можу захотіти зупинити виконання, а бувають випадки, коли я цього не роблю.
І звичайно, я міг би написати дві окремі функції, але якщо це єдина функція, яка це робить, я з цим погоджуюсь.
Заяви про заборонений вихід
Іншим інструментам якості коду не подобається оператор виходу (і, аналогічно, їм не подобається оператор die ). І це зрозуміло: вони зазвичай призводять до повної зупинки програми, коли ми маємо створити виняток, повернути значення або взагалі щось зробити, щоб грамотно впоратися з ситуацією.
Знову ж таки, однак, оскільки в цій функції бувають випадки, коли я хочу зупинити виконання, я добре маю справу з наслідками наявності рядка коду у функції.
Крім того, я міг би використати wp_die(), і більшість інструментів якості коду навряд чи вловлять його, але це маскує головну проблему. У будь-якому випадку, можливо, найкраще просто придушити попередження за допомогою будь-якої директиви, яку може дозволити ваш сніфер.
Незважаючи на це, зареєструйте повідомлення
Зрештою, мета вищезазначеної функції полягає в тому, щоб надати простий спосіб запису в журнал налагодження WordPress і, за бажанням, зупинити виконання програми під час цього.
Очевидно, що це не без проблем, і є доступні бібліотеки вищої якості, але іноді вам не потрібна кувалда для проблемної кнопки.