Natchnęło mnie dziś do pomyślenia jak uchronić się przed niebezpieczeństwami związanymi z stosowaniem die() w kodzie…tak wiem że była o tym parę razy mowa, że to zło w najczystszej postaci,  że najlepiej korzystać z xdebug, a najlepiej nigdy nie korzystać z die() w kodzie.

Wszystko ma jednak swoje wady i zalety – o ile w pracy xdebuga mogę sobie skonfigurować pod netbeansa to w domu nie korzystam z tego IDE (połączenie przez OpenVPN i dość częste skanowanie projektu jest nader uciążliwe). Dlatego zaczerpnąłem nieco mocy googla i po kilku testach przedstawiam:  FirePHP.

FirePHP to całkiem zgrabny logger dla PHP wykorzystujący Firebuga – ku mojemu zdziwieniu jest to całkiem niezły plugin, do jego działania wystarczy mieć zainstalowaną wtyczkę Firebug z włączoną zakładką sieć i konsola. Instalując FirePHP trzeba jeszcze pamiętać o zaciągnięciu biblioteki FirePHPCore, którą rozpakowujemy do katalogu roota (w moim przypadku to katalog web w symfony).  FirePHP pokaże się jako niebieski robal (widoczny na poniższym zrzucie).

Mając to wszystko jesteśmy niemal gotowi by bezpiecznie debugować skrypty. Do skryptu dołączamy:

require_once('FirePHPCore/FirePHP.class.php');

Teraz już poprzez wywołanie w postaci:

$firephp = FirePHP::getInstance(true);
$firephp->log($var, 'nieobowiazkowy opis dla loga');

Zobaczymy w zakładce konsola Firebuga wartość zmiennej $var poprzedzoną opisem podanym jako drugi parametr funkcji log.
Dla własnej wygody napisałem krótką funkcję ustawiającą podstawowe parametry debugowania:

/**
* Function is used for debuging this scrypt, in prod environment change
* $firephp->setEnabled(true); to false.
*
* @param object $var
* @param string $desc[optional]
*/
public function keep($var, $desc = null)
{
  $options = array(
  'maxObjectDepth' => 10,
  'maxArrayDepth' => 20,
  'useNativeJsonEncode' => true,
  'includeLineNumbers' => true);

  $firephp = FirePHP::getInstance(true);
  $firephp->setEnabled(true);
  $firephp->setOptions($options);
  $firephp->log($var, $desc);
}

Ważne aby pamiętać iż dla własnego bezpieczeństwa należy w środowisku produkcyjnym ustawić setEnabled na false.

Posłużę się Jobeetem, zatem moja funkcja index wygląda tak:

public function executeIndex(sfWebRequest $request)
{
  $vars = 0;
  $this->categories = Doctrine::getTable('JobeetCategory')->getWithJobs();
  $this->keep($vars, "at line: ".__LINE__);
  $vars = 12;
  $this->keep($vars, "at line: ".__LINE__);
}

drugi parametr funkcji keep służy mi jako informacja pozwalająca szybko odnaleźć miejsce z wywołaniem logera. Wynik logowania prezentuje się następująco:

Ciekawsze wyniki można uzyskać deklarując przykładową tablicę z danymi – najeżdżając kursorem myszy na wynik debugowania tablicy ukaże się okienko jak na poniższym zrzucie – możemy tutaj nieco dokładniej przyjrzeć się zwróconym wartościom.

Na koniec chciałbym zauważyć, że odświeżenie strony nie zawsze powoduje odświeżenie wyników debugowania, prowadzi to wręcz do ich utraty – należy wówczas kliknąć w Firebugu opcję Off a następnie On dzięki czemu zobaczymy aktualne dane.

Zachęcam do korzystania z FirePHP i testowania jego pozostałych funkcjonalności.

http://www.firephp.org/HQ/Use.htm

Na pierwszy ogień testów poszedł phpCodeBeautifier. Szybko jednak okazało się, że klamra otwierająca zawartość klasy musi znajdować się w tej samej linii co jej deklaracja. Istnieje opcja:

--space-before-start-angle-bracket

która pozwala wymusić jeden znak spacji przed “{“. Czemu autorzy nie pomyśleli o

--newline-before-start-angle-bracket

? Cieżko powiedzieć. Kod jest zamknięty, więc się tego nie dopisze samemu.

Istnieje jednak PHP_CodeSniffer (phpcs), który połączony z odpowiednim standardem sprawdzi składnie pliku.

Zainstalujmy “to” wszystko… Na początek instalacja samego phpcs:

apt-get install php-codesniffer

Aby aplikacja mogła sprawdzać formatowanie zgodne z symfony należy jeszcze doinstalować standard symfony. Można go znaleźć w repozytorium svn pod adresem http://subversion.assembla.com/svn/phpsymfony/Symfony%20Code%20sniffer%20standards/Symfony/.

 cd /usr/share/php/PHP/CodeSniffer/Standards && sudo svn co http://subversion.assembla.com/svn/phpsymfony/Symfony%20Code%20sniffer%20standards/ .

Do przetestowania programu stwórzymy plik:

vim ~/test.php

z odpowiednią zawartością:

<?php
class TestKlasa
{
  public function testFunction()
  {
  }
}

Uf, nareszcie możemy sprawdzić czy nasz kod jest poprawny:

phpcs --standard=Symfony ~/test.php

W wyniku czego otrzymamy:

FILE: ~/test.php
--------------------------------------------------------------------------------
FOUND 3 ERROR(S) AND 0 WARNING(S) AFFECTING 2 LINE(S)
--------------------------------------------------------------------------------
2 | ERROR | Missing file doc comment
2 | ERROR | Missing class doc comment
4 | ERROR | Missing function doc comment
--------------------------------------------------------------------------------

Działa! To znaczy są błędy, ale o to właśnie nam chodziło – aby je wykrywać. Poprawmy więc zawartość pliku:

<?php
/**
* Test file for PHP_CodeSniffer
*
* PHP versions 4 and 5
*
* @category Tests
* @package  XX
* @author   Marcin Dryka <marcin.dryka@xsolve.pl>
* @license  http://www.opensource.org/licenses/lgpl-license.php LGPL
* @version  SVN: 1
* @filesource
*/

/**
* TestKlasa
*
* @package XX
* @author  Marcin Dryka <marcin.dryka@xsolve.pl>
* @version Release: 1
*/
class TestKlasa
{
  /**
  * testFunction
  *
  * @author Marcin Dryka <marcin.dryka@xsolve.pl>
  * @access public
  * @return void
  */
  public function testFunction()
  {
  }
}

Przy tak wyglądającym pliku wynik działania phpcs jest pusty, brak błędów oznacza poprawnie sformatowany plik. Teraz potrzebna jest tylko silna wola, aby używać skryptu do sprawdzania wszystkich plików. Przy starszych aplikacjach będzie to dość kłopotliwe. Zdarzają się jednak pliki pisane od tak zwanego zera. Gdzie możemy w pełni stosować konwencje ustalone przez autorów symfony (i nie tylko).