Чем вы отлаживаете PHP код для сайта
- А они у меня не болеют...
Я никакой не использую. Мне лень :) как то привык работать с PHP без дебага. Пишу сразу безошибочный код :)
в чем опасность - "без дебага"? не очень понял глубину сего.
Ты вероятно путаешь дебаг и модульное тестирование, или нечто подобное. Ибо если ты при помощи дебагера ищешь ошибки в проекте - то должен тебе заметить либо твои проекты весьма малы, либо ты просто говоришь о том в чем плохо разбираешься. ЧТо впрочем не исключает одно другого.
не вариант, мне проект на zend framework так проверять.
в чем опасность - "без дебага"? не очень понял глубину сего.
Ты вероятно путаешь дебаг и модульное тестирование, или нечто подобное. Ибо если ты при помощи дебагера ищешь ошибки в проекте - то должен тебе заметить либо твои проекты весьма малы, либо ты просто говоришь о том в чем плохо разбираешься. ЧТо впрочем не исключает одно другого.
Проекты мои весьма малы, а подход безалаберный. Модульне тестирования я не знаю что это, так что путать не могу.
Под дебагом подразумеваю вывод информации об ошибке во время исполнения куда либо.
То, что я сказал, с вашим умудренным опытом, видимо прозвучало как несуразица.
Удаляюсь
собственно с цитатой практически полностью согласен:
Причина, по которой я не пользуюсь отладчиками — моя уверенность в том, что отладчики заставляют лениться. Обнаружив ошибку, многие разработчики запускают отладчик, выставляют точки останова и исследуют память или значения переменных. Легко поддаться очарованию от такого мощного инструмента, но недостаточные размышления приведут к большей потере времени. А если ваша программа такая сложная, что отладчик вам необходим, см. п.2
«Год или два, с момента начала работы в Bell Labs, я работал в паре с Кеном Томпсоном над интерактивным графическим языком, разработанным Джерардом Хольцманом (Gerard Holzmann). Я печатал быстрее, поэтому я сидел за клавиатурой, а Кен стоял позади меня. Мы работали быстро, и когда компилятор выдавал ошибку, я рефлективно начинал закапываться в проблему, изучая стек вызовов, вывод программы, запускал отладчик и так далее. Но Кен просто стоял рядом и думал, игнорируя меня и код, который мы только что написали. Вскоре я заметил закономерность: Кен зачастую понимал, в чем проблема, раньше меня и произносил: „Я знаю, что не так“. Обычно он был прав. Я понял, что Кен выстраивал ментальную модель кода и, когда что-то ломалось, это была ошибка в модели. И думая о том, как эта проблема могла возникнуть, он выяснял, в каком месте модель была неверна или где наш код мог неправильно эту модель отразить.
Кен научил меня, что думать перед отладкой чрезвычайно важно. Если вы начинаете погружаться в ошибку, с большей вероятностью вы устраните локальную проблему в коде, но если вы сначала подумаете об ошибке, каким образом она могла возникнуть, вы найдете и исправите в коде ошибку более высокого уровня, что позволит улучшить архитектуру и предотвратить появление подобных ошибок в будущем.
Я понимаю, что это больше вопрос стиля. Некоторые настаивают на построчной отладке всего на свете специализированными инструментами. Но я теперь верю, что думать, не глядя в код, — это лучший инструмент отладки, потому что он ведет к лучшему программному обеспечению». — Роб Пайк
я себе во всех входных файлах пишу функцию:
echo "<pre>";
$dump ? var_dump($arr) : print_r($arr);
echo "</pre>";
if ($die)
exit();
}