6.3Best practices & pitfalls
The essentials in 30 seconds
- Golden rule: clean code, systematic distrust of inputs, structure and delivery — safety pays, never raw speed.
- Do: === and strict_types, prepared statements + escaping, MVC + Composer, password_hash + .env, PHPUnit, measure then deliver.
- Avoid: SQL concatenation, raw display, plain-text secrets, client-side-only validation, neglected tests, exposed errors.
Riad thread — three habits that pay
After one year, Riad draws his conclusions: what counted most was not a framework but three habits — comparing strictly and typing, preparing every query and escaping every display, and delivering all the way with tests and deployment. And his biggest narrowly avoided pitfall: a plain-text stored password during a rush week.
Pick a single habit to anchor in your ritual, then move to the next.
What makes the difference
The difference between tinkering and professional practice is not the tools but the reflexes: writing clean code, never trusting inputs, structuring, testing, and delivering.
✓ Do
- Write modern PHP: === by default, typing (declare(strict_types=1)), single-responsibility functions.
- Never trust inputs: server-side validation, prepared statements, escape on display.
- Structure (MVC, logic/display separation) and leverage Composer (autoloading, battle-tested libraries).
- Hash passwords (password_hash), protect secrets (environment variables), HTTPS, authorisation.
- Write tests (PHPUnit) on critical logic; measure before optimising.
- Rely on frameworks (default protections) and deliver all the way (deployment, CI/CD).
✗ Avoid
- Concatenating data into SQL (injection) or displaying raw data (XSS).
- Storing a plain-text password or a secret in the Git repo.
- Relying on client-side validation (bypassable); mixing logic and display (spaghetti).
- Neglecting tests (“it works”) and letting silent regressions through.
- Premature optimisation instead of measuring and targeting; over-engineering.
- Displaying detailed errors in production (information disclosure).
Ready-to-say script — checking your practice before delivering (30 s)
“strict_types and ===? Inputs validated server-side, SQL prepared, display escaped, CSRF? password_hash, secrets in .env, HTTPS, authorisation? PHPUnit green, errors logged? If any no, I fix before delivering.”
Copy-paste template — safe sign-up (hashing + prepared)
prepare("INSERT INTO users (email, hash) VALUES (:email, :hash)");
$stmt->execute(["email" => $email, "hash" => $hash]);
function verifier(string $saisi, string $hash): bool {
return password_verify($saisi, $hash);
}VSE / small budget
One single habit per quarter is enough: prepared statements first, the rest after.
SME Constantine
Adapt rituals to peaks and travel: a code-review and test slot held every week.
Remote / hybrid
The #1 discipline at a distance: written reviews and green tests, even for small fixes.
Intercultural
Check local practices rather than assume: an unusual authorisation rule must raise flags everywhere.
48h challenge — apply tomorrow
Screen your main page: zero SQL concatenation, zero raw display, zero versioned secret. Fix the first gap found.
- I know the reflexes to adopt and the pitfalls to avoid.
- I checked my 3 critical points (SQL, display, secrets).
- I did the 48h challenge or scheduled its date.
Before delivering, Riad checks his practice. Which reflex protects him best?
Golden rule: a good PHP developer is not the one who codes fastest, but the one whose applications are clean, safe, maintainable and actually delivered to production.