Debugging PHP
debt(d3/e1/b1/t5)
Closest to 'default linter catches the common case' (d3). Pre-commit hooks and basic linters can catch leftover var_dump()/dd() calls in committed code. However, the deeper issue of not using proper debugging tools at all is not detectable by any tool — it's a skill gap, not a code smell. The common mistake of leaving debug statements is catchable, so d3.
Closest to 'one-line patch or single-call swap' (e1). The quick_fix states: install Xdebug, configure IDE, set breakpoint. Removing a stray var_dump() is literally deleting one line. Adopting better debugging practices is not a code fix — it's a developer skill change, which doesn't score on Effort. The actual code remediation is trivial.
Closest to 'minimal commitment' (b1). Debugging is a developer activity, not an architectural choice that imposes ongoing structural debt. Using var_dump() vs Xdebug doesn't create technical debt that poisons the codebase or becomes load-bearing. It affects developer productivity but not code structure.
Closest to 'notable trap' (t5). The misconception field explicitly states that developers believe 'var_dump() is sufficient for all debugging needs' — this is a documented gotcha that most PHP developers eventually learn through painful experience. It's not catastrophic (the code still works), but it's a significant time sink that contradicts how debugging works in other ecosystems where step-debuggers are standard from day one.
Also Known As
TL;DR
Explanation
PHP debugging escalates through levels of sophistication: basic output debugging (var_dump(), print_r(), dd() in Laravel — quick but not suitable for production); error log inspection (tail /var/log/php/error.log or Laravel's storage/logs/laravel.log); Xdebug step debugger (breakpoints, step-through, variable inspection in PhpStorm or VS Code — the most powerful technique); PHPStan/Psalm static analysis (finds type errors, undefined variables, dead code without running the code); profiling (Xdebug profiler, Blackfire — identifies slow functions rather than incorrect behaviour). The debugging mindset: state a hypothesis ('the user ID is null at this point'), verify it (var_dump($userId) or a breakpoint), revise the hypothesis based on evidence. The most common debugging mistake is adding output statements randomly rather than systematically narrowing down the location of the problem.
Common Misconception
Why It Matters
Common Mistakes
- Leaving var_dump() or dd() calls in committed code — use a pre-commit hook to catch debug statements.
- Not checking the PHP error log first — most bugs announce themselves immediately in the error log.
- Debugging in production — replicate the issue locally or in a staging environment; adding debug output to production exposes internals.
- Not using static analysis — PHPStan level 6+ catches type errors, null dereferences, and undefined variables before you even run the code.
Code Examples
// Scattered var_dumps — easy to forget to remove
function processOrder(array $data): Order {
var_dump($data); // LEFT IN PRODUCTION
$total = 0;
foreach ($data['items'] as $item) {
var_dump($item); // LEFT IN PRODUCTION
$total += $item['price'];
}
return Order::create(['total' => $total]);
}// Laravel dd() for development — throws, never silently continues
// But better: use Xdebug breakpoint instead of any output
// PHPStan catches bugs before runtime
// vendor/bin/phpstan analyse src/ --level=6
// Found 3 errors:
// - Undefined variable: $userId
// - Cannot call method find() on null
// - Function processOrder() should return Order but returns void
// In php.ini / xdebug.ini:
// xdebug.mode=debug
// xdebug.start_with_request=yes
// Then set breakpoint in IDE — no code changes needed