Za każdym razem, gdy pracuję nad projektem, często mam WordPress ustawiony w trybie debugowania i lubię pisać komunikaty w dzienniku błędów, które mogę łatwo przeglądać, śledzić i śledzić za każdym razem, gdy pracuję nad projektem.
Kiedy to robię, są dwa sposoby (i to tylko zależy od projektu):
- Użyję biblioteki takiej jak Monolog ,
- Użyję własnej, prostej funkcji dziennika.
W tym poście omówię to drugie. Oznacza to, że podzielę się tym, w jaki sposób piszę wiadomości do dziennika debugowania WordPressa, a następnie o niektórych rzeczach, na które musisz zwrócić uwagę, gdy robisz to samo.
Dziennik debugowania WordPressa
Po pierwsze, należy zauważyć, że funkcja, którą zamierzam udostępnić, jest zwykle w kontekście klasy bazowej.
Załóżmy, że mam AbstractSubscriber, który implementują wszyscy moi subskrybenci (np. ScriptAssetSubscriber do rejestracji i kolejkowania pliku JavaScript).
AbstractSubscriber będzie zawierał tę funkcję, dzięki czemu może być wywoływana przez dowolne klasy podrzędne. Funkcja jest dość prosta:
<?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;
}
}Jest jednak kilka rzeczy związanych z tą funkcją, które mogą naruszać zasadę lub powodować błędy w narzędziach jakości kodu.
Opcjonalne argumenty logiczne
Za każdym razem, gdy funkcja akceptuje opcjonalny argument logiczny, może to wskazywać, że funkcja ma więcej niż jedną odpowiedzialność (w ten sposób naruszając zasadę pojedynczej odpowiedzialności ).
Powodem, dla którego naruszyłoby to wspomnianą zasadę, jest to, że daje modułowi więcej niż jeden powód do zmiany.
Czuję się komfortowo pozwalając, aby to zostało napisane w ten sposób, ponieważ używam go do debugowania, a nie w środowiskach produkcyjnych, i ponieważ są chwile, w których mogę chcieć zatrzymać wykonanie, a czasami nie.
I oczywiście, mógłbym napisać dwie oddzielne funkcje, ale jeśli jest to jedyna funkcja, która to robi, to nie przeszkadza mi to.
Wyciągi o zakazie wyjścia
Inne narzędzia jakości kodu nie lubią instrukcji exit (i podobnie nie lubią instrukcji die ). I jest to zrozumiałe: zazwyczaj powodują całkowite zatrzymanie programu, gdy powinniśmy zgłosić wyjątek, zwrócić wartość lub ogólnie zrobić coś, aby zgrabnie poradzić sobie z sytuacją.
Znowu jednak, ponieważ w tej funkcji są chwile, w których chcę zatrzymać wykonanie, nie mam nic przeciwko konsekwencjom posiadania wiersza kodu w funkcji.
Alternatywnie mógłbym użyć wp_die(), a większość narzędzi jakości kodu prawdopodobnie by tego nie wyłapała, ale to maskuje główny problem. Jeśli już, to może najlepiej po prostu stłumić ostrzeżenie za pomocą dowolnej dyrektywy, na którą pozwala twój wybrany sniffer.
Niezależnie od tego, zapisz wiadomość
Ostatecznym celem powyższej funkcji jest zapewnienie prostego sposobu zapisywania w dzienniku debugowania WordPressa i opcjonalnie zatrzymanie wykonywania programu podczas wykonywania tego.
Oczywiście nie jest bez problemów i istnieją biblioteki wyższej jakości, które są dostępne, ale czasami nie potrzebujesz młota, aby rozwiązać problem.