Common PHP Pitfalls

Analogy categoryAnalogies

PHP's flexibility is also its biggest liability: the language was designed to 'just work' with loosely typed, forgiving semantics, and many of its most infamous bugs come from that forgiveness silently masking a mistake rather than failing loudly. Knowing these pitfalls by name — and recognizing the code patterns that trigger them — is one of the fastest ways to level up from someone who writes PHP that runs to someone who writes PHP that's correct.

🏏

Cricket analogy: A flat, forgiving pitch lets a batter get away with a loose shot that would have been bowled clean on a green seamer; PHP's loose typing is that same forgiving pitch, letting sloppy code survive instead of collapsing loudly.

Loose comparison surprises

Before PHP 8, comparing a numeric string to a non-numeric string with == could produce results that violated intuition — for instance, 0 == 'abc' used to evaluate to true because the string was cast to the number 0. PHP 8 fixed the most dangerous cases (non-numeric strings compared to numbers no longer coerce the string), but == still coerces types in ways === does not, so mixed-type comparisons remain a common source of subtle logic bugs, especially with data coming from $_GET/$_POST, which is always a string.

🏏

Cricket analogy: Before DRS, an umpire's gut call of 'not out' on a marginal LBW could be wrong in ways nobody could verify; PHP 8 tightening 0 == 'abc' is like introducing DRS to catch a call that used to slip through incorrectly.

Array and reference gotchas

Passing arrays by reference in a foreach (foreach ($arr as &$value)) leaves $value bound to the last array element after the loop ends. If that same variable name is reused in a subsequent foreach without unset(), the new loop silently overwrites array elements instead of iterating cleanly — a bug that produces no warning and can corrupt data invisibly. Another common trap is assuming arrays are passed by reference by default; PHP arrays are value types and are copied on write, so mutating a function's array parameter does not affect the caller's array unless it's explicitly passed by reference.

🏏

Cricket analogy: A fielder left standing at the exact spot of the last catch, then unknowingly repositioned there again for the next over without a fresh team huddle, ends up out of position and confuses the whole field — like a stale &$value reference silently overwriting new data.

Mutable static state and object cloning

Objects, unlike arrays, are passed by handle — assigning an object to a new variable or passing it to a function does not copy it, so mutating it in one place mutates it everywhere else it's referenced. Developers coming from array semantics often assume $copy = $original deep-copies an object and are surprised when both variables mutate together; clone performs a shallow copy, and __clone() must be implemented explicitly for deep copies of nested objects.

🏏

Cricket analogy: Handing the team captaincy armband to a new player doesn't create a second captain — there's still one authority, and any decision made with it affects the whole team, just as an object passed by handle stays one shared instance everywhere it's referenced.

php

// Pitfall: dangling reference from foreach
$numbers = [1, 2, 3];
foreach ($numbers as &$n) {
    $n *= 2;
}
unset($n); // REQUIRED to break the reference

$letters = ['a', 'b', 'c'];
foreach ($letters as $n) { // reuses $n, now aliased to $numbers[2]
    // without unset() above, $numbers[2] silently gets overwritten here
}

// Pitfall: objects are handles, not values
final class Counter { public int $count = 0; }
$a = new Counter();
$b = $a;          // $b references the SAME object as $a
$b->count = 5;
echo $a->count;   // 5 -- surprising if you expected array-like copy semantics

A good habit that eliminates several of these classes of bugs at once: prefer === over == unless you have an explicit, documented reason to want type coercion, and always unset() reference variables immediately after the loop that created them.

String interpolation of user-controlled values into include/require paths is both a correctness pitfall and a critical security hole (local file inclusion). Always validate against an allow-list rather than trusting a filename fragment from user input.

== still coerces types even in modern PHP; prefer === unless coercion is explicitly intended.
Always unset() a foreach ($arr as &$value) reference variable to avoid silently corrupting later loops.
PHP arrays are value types (copy-on-write); objects are handles and are shared by reference by assignment.
clone performs a shallow copy — implement __clone() for correct deep copies of nested objects.
Data from $_GET/$_POST is always a string, so comparisons against it can trigger unexpected type coercion.
Never interpolate untrusted input directly into file-inclusion paths — validate against an allow-list.

Practice what you learned

1. What happens if you forget to `unset()` the reference variable after `foreach ($arr as &$value)`?

2. How are PHP objects handled when assigned to a new variable, compared to arrays?

3. What does `clone $obj` do by default?

4. Why can comparing `$_GET['id'] == 0` behave unexpectedly?

5. What is the security risk of interpolating user input into an `include` path?

Was this page helpful?

PHP Interview Questions

PHP Quick Reference

Related Study Notes in Programming

Browse all study notes

Programming

Apache Spark Study Notes

Programming · 30 topics

Programming

Apache Flink Study Notes

Programming · 30 topics

Programming

Hadoop Study Notes

Programming · 30 topics

Programming

Snowflake Study Notes

Programming · 30 topics

Programming

Apache Airflow Study Notes

Programming · 30 topics

Programming

dbt (Data Build Tool) Study Notes

Programming · 30 topics

Topics covered

#PHP#PHPProgrammingStudyNotes#Programming#CommonPHPPitfalls#Common#Pitfalls#Loose#Comparison#StudyNotes#SkillVeris

Common PHP Pitfalls