PHP (Stack) code review rules

Wrap file reads/writes (e.g., file_get_contents, file_put_contents, fopen) with checks and exceptions; never assume the filesystem is available.

Check transport errors and HTTP status codes before parsing response bodies; treat 4xx/5xx as errors with context.

Do not use the eval() function to run dynamically generated PHP code, especially if it can include user input. Look for safe alternatives like controlled function calls or explicit decision structures.

Configure your application not to display detailed error messages (stack traces, PHP warnings) to end users in production. Instead, log errors for developers and show a generic message to users.

Avoid hard‐coding credentials or sensitive information (like DB passwords, API tokens or secret keys) directly in your code. Use separate configuration files or environment variables to manage these values securely.

Avoid passing untrusted values to include/require statements. If you need to include files based on external input, strictly validate that input (for example, using a whitelist of valid filenames).

When sending session or other sensitive cookies, always enable the HttpOnly and Secure flags (and consider SameSite). HttpOnly prevents JavaScript access, and Secure ensures the cookie is only sent over HTTPS.

Always escape or sanitize user‐provided content before displaying it in HTML. Use functions like htmlspecialchars() to convert special characters into HTML entities.

Use transactions for multi-step writes; on Throwable, rollback and rethrow with context.

Use JSON_THROW_ON_ERROR (PHP ≥7.3) and wrap json_encode/json_decode in try/catch; validate the decoded shape.

Log errors with operation name and identifiers (e.g., userId, orderId) using structured context.

Replace per-row lookups with JOINs or bulk queries to fetch related data in fewer round-trips.

Implement anti‐CSRF tokens in forms performing sensitive actions (like state changes or deletions). Generate a unique token per session or request and validate it on the server before processing the form action.

Return 2xx only on success; use 4xx for client errors and 5xx for server errors, with a minimal JSON error body.

Background jobs must throw on irrecoverable failures (after logging) so the runner/queue can retry or dead-letter appropriately.

For security tokens (session IDs, CSRF tokens, password‐reset links), use cryptographically secure random functions like random_bytes() or openssl_random_pseudo_bytes(), instead of predictable functions like rand() or mt_rand().

Do not build SQL queries by directly concatenating untrusted data. Instead, use prepared statements with parameters (for example, using PDO or MySQLi) to prevent SQL Injection.

Do not use weak or generic hash algorithms (like MD5 or SHA1) for storing passwords. Use built‐in functions like password_hash() (with BCRYPT or Argon2) and password_verify(), which handle salting and secure algorithms automatically.

Wrap per-item work in try/catch, collect failures, and continue when appropriate; never let one failure abort the entire batch by default.

Never trust data received from users, forms or requests. Always validate the expected format (e.g., numbers, emails) and sanitize/remove unexpected characters or content using appropriate techniques (filter_var, filter_input, etc.).

After decoding, assert required keys and types before use; reject unexpected shapes.

Use isset()/array_key_exists() or null coalescing (??) before reading array keys that may be absent.

Every match expression must define a default arm that handles unsupported or unexpected values.

Do not perform multiple DB queries inside a loop for data you could fetch in one query. Instead, consolidate using IN clauses or JOINs to retrieve all needed data at once.

Do not use global variables to share data across your program. Prefer passing values as function parameters or using configuration objects. Limiting variable scope makes code more predictable and less prone to side effects.

Do not use the error‐suppression operator '@' before function calls or expressions. Instead, handle potential errors properly using return checks or exceptions (try/catch).

Cache frequently used, rarely changing query results in memory or an external cache with appropriate TTL/invalidations.

Define configuration values in one place (env/config file/const class) and reference them; avoid scattering magic strings.

Extract reusable SQL fragments/builders for commonly repeated WHERE/ORDER clauses.

Always specify access levels (public, private, protected) when declaring class properties and methods. Don’t use the old `var` keyword for properties. Explicit visibility clarifies intent and prevents unintended access.

Avoid empty catch blocks. When you catch an exception, implement meaningful handling: log the error, perform a fallback action, or rethrow after processing. Do not catch exceptions generically just to suppress them.

Avoid functions or extensions deprecated in recent PHP versions (e.g., mysql_* or preg_replace without proper delimiters). Use modern supported alternatives like PDO/MySQLi for DB or PCRE functions (preg_match, preg_replace with correct syntax).

Avoid using the `goto` statement for flow control. Instead, refactor code using loops (for, while) and conditional structures (if/else, switch) for clear and maintainable logic.

At the top of your PHP files (before any code), declare `declare(strict_types=1)`. This forces PHP to enforce the declared parameter and return types strictly, avoiding automatic type coercion.

Move repeated domain calculations/transformations into named functions or service classes; keep controllers/scripts thin.

Use ?? and the nullsafe operator (?->) to provide defaults and avoid notices when values may be null.

Write functions and methods so each does one well-defined task. If a function handles distinct steps (validation, processing, saving, notifying), refactor into smaller focused functions.

Use strict comparison operators (=== and !==) instead of loose (== and !=) in most cases. Strict comparisons check both type and value, avoiding PHP’s implicit type coercion pitfalls.

After using external resources (DB connections, open files, sockets), release them properly. Use fclose(), close database connections or finally blocks to ensure cleanup even if errors occur.

Deduplicate identical queries within a request; reuse previously fetched data or preload in a single query.

Eliminate debug helpers (var_dump, die, print_r) and commented-out blocks before merging.

Do not use echo/var_dump for diagnostics in application code; use a PSR-3 logger or error_log with levels.

Prefer set-based SQL (DELETE/UPDATE with WHERE IN/JOIN) or chunked batches over per-row statements.

Always specify ORDER BY when the processing logic relies on a particular order.

Stream results (cursor/generator) or paginate instead of loading entire result sets into memory.

Add scalar/union/nullable type hints and return types to functions, methods, and properties; prefer interfaces over mixed.