WordPress Coding Standards: A Practical Review Checklist

Run PHP_CodeSniffer with the WordPress ruleset in CI, and stop discussing formatting in reviews. The standard covers indentation, naming, spacing, documentation blocks and a useful set of security checks — unescaped output and unsanitised input among them.

Add a PHP compatibility check against your minimum supported version too, which catches syntax and functions that will fatal on an older server.

Once those run automatically, review conversations move to the things that actually need judgement.

• Is every dynamic value escaped at the point of output? esc_html for text, esc_attr for attributes, esc_url for URLs, wp_kses_post for content that may legitimately contain markup.
• Escape late — at output, not when storing. Data that was safe when stored may not be safe in the context it's finally used.
• Is anything being echoed without escaping because 'we put it there ourselves'? That's the assumption most XSS holes are built on.
• Are translated strings escaped? esc_html__ rather than __ followed by a raw echo.
• Is JSON output through wp_json_encode rather than hand-built?

• Is every value from a request sanitised with a function appropriate to its type, not just run through a generic one?
• Is it validated as well as sanitised? Sanitising makes a value safe; validating confirms it's the right value.
• Is there a nonce on every form and AJAX action that changes something, and is it verified server-side?
• Is there a capability check with current_user_can? A nonce proves intent, not permission — you need both.
• For actions on a specific object, is the capability checked against that object's ID?
• Does any custom SQL use $wpdb->prepare? And could it use a WordPress API instead of custom SQL at all?
• Are file uploads restricted by type, and stored somewhere PHP can't execute?

• Any queries inside a loop? That's an N+1 problem and it's the most common performance bug in WordPress code.
• Is posts_per_page bounded, or could it be -1 on a table that grows?
• Are no_found_rows and fields used where the full result isn't needed?
• Are meta queries being used where a taxonomy would be faster?
• Is anything making a remote HTTP request during a page render? That blocks PHP until the remote server answers.
• Are expensive results cached in a transient, with invalidation on the event that makes them stale?
• Are assets enqueued conditionally, or loaded on every page regardless of need?

• Is the hook the right one? Registering post types on init, not plugins_loaded. Not using conditional tags before the query has run.
• Do filter callbacks always return a value on every code path? A filter returning nothing is the most common hook bug there is.
• Is priority set deliberately where order matters, rather than relying on luck?
• Are callbacks named and referenced properly, so they can be removed by other code? An anonymous function attached to a hook can never be unhooked.
• Is anything hooked that runs on every request but is only needed in one context?

This is the question that decides whether a site is maintainable in three years, and it's the one a linter cannot ask.

• Is anything in the theme that should be in a plugin? Custom post types, shortcodes, integrations, business logic — all of it disappears or breaks on a theme change.
• Is the theme's functions.php a single enormous file, or does it require focused files from an includes directory?
• Is logic separated from presentation, so templates contain markup rather than queries?
• Is anything duplicated that should be a shared function or template part?
• Are things named for what they are rather than how they currently look?

• Is everything prefixed or namespaced? Unprefixed function names in the global scope will collide eventually.
• Are option names, meta keys, post type keys and taxonomy slugs prefixed too?
• Are meta keys intended to be internal prefixed with an underscore so they don't show in the custom fields UI?
• Are class names, hooks and constants consistently named across the codebase?

• Are user-facing strings wrapped in translation functions with a consistent text domain?
• Do strings with placeholders use printf-style formatting rather than concatenation, so translators can reorder?
• Do generated form fields have associated labels?
• Do images output by templates have alt attributes, with a way for editors to set them?
• Are interactive elements actual buttons and links rather than divs with click handlers?
• Does the markup use heading levels in order?

Comments explaining what a line does are noise; the code says that already. Comments explaining why are the ones worth writing, and they are the ones missing from almost every WordPress codebase I inherit.

• Does a non-obvious workaround say what it works around? A line that exists because of a plugin bug is incomprehensible once the bug is fixed and forgotten.
• Do functions with several parameters have a docblock saying what each is and what comes back?
• Is there a note where an integration expects a particular remote response shape, so the next person knows what breaks it?
• Does the repository have a readme covering local setup, the deploy process and where configuration lives?
• Are magic values named? A bare number in a condition is a question nobody can answer in six months.

• What happens on a fresh install with no content? Empty states are where template code throws notices.
• What happens when an expected custom field is missing, which is what old content looks like after a new field is added?
• Are errors handled, or does the code assume every API call and query succeeds?
• Is anything logging personal data?
• Does the code work with the site in a subdirectory, and with HTTPS?
• Has anyone actually run it with WP_DEBUG on? Notices and deprecations are where tomorrow's fatal errors are visible today.