How to Write Clean WordPress Code

WordPress powers 43% of the web, which means there is a LOT of bad code out there.

Writing "clean" code isn't about being a perfectionist. It's about ensuring your code doesn't crash a client's site three years from now when PHP updates.

Here are the golden rules of WordPress development.

---

1. Prefix Everything

If you name a function get_posts(), you are going to break someone's site because WordPress core or another plugin already uses that name.

Always add a unique prefix to your global functions, classes, and variables.

• Bad: function save_settings() { ... }
• Good: function my_agency_save_settings() { ... }

---

2. Escape Late, Sanitize Early

This is the mantra of WordPress security.

• Sanitize Early: Clean data the moment it enters your application (from $_POST or $_GET).
• Escape Late: Clean data the moment you output it to the screen (echo).

Example:

// Sanitize Input
$user_name = sanitize_text_field( $_POST['name'] );

// Escape Output
echo 'Hello, ' . esc_html( $user_name );

---

3. Use Nonces for Actions

If you have a form that saves settings or deletes a post, you MUST use a "Nonce" (Number used ONCE). This prevents CSRF (Cross-Site Request Forgery) attacks where a hacker tricks an admin into clicking a "delete" link.

// In Form
wp_nonce_field( 'my_delete_action', 'my_nonce_field' );

// In Processor
if ( ! isset( $_POST['my_nonce_field'] ) || ! wp_verify_nonce( $_POST['my_nonce_field'], 'my_delete_action' ) ) {
   die( 'Security check failed' );
}

---

4. Code Standards (Tabs vs Spaces)

WordPress has strict coding standards (WPCS).

• Use Tabs for indentation, not spaces.
• Put spaces around parentheses: if ( $condition ).
• Brace goes on the same line: function foo() {

Following these standards makes your code look like "WordPress native" code, making it easier for other developers to read.

---

5. Comment Your Code (PHPDoc)

Code tells you how, comments tell you why. In WordPress, we use the specific PHPDoc format. This allows IDEs (like VS Code) and documentation generators to understand your code structure.

/**
 * Register a custom post type.
 *
 * @since 1.0.0
 * @param string $slug The post type slug.
 * @return void
 */
function my_agency_register_cpt( $slug ) {
    // ...
}

---

6. Use Internationalization (i18n)

Never hardcode English text strings. What if your client wants the site in Spanish later?

Wrap all readable text in __() functions.

• Bad: echo 'Read More';
• Good: echo __( 'Read More', 'my-text-domain' );
• Good (Echoing directly): _e( 'Read More', 'my-text-domain' );

---

7. Stop Writing Raw SQL

WordPress has an incredible database abstraction layer. If you are writing SELECT * FROM wp_posts, you are doing it wrong.

Usage of WP_Query is caching-friendly, secure by default, and much easier to read.

Bad (Raw SQL):

$posts = $wpdb->get_results( "SELECT * FROM $wpdb->posts WHERE post_status = 'publish'" );

Good (WP_Query):

$args = array(
    'post_status' => 'publish',
);
$query = new WP_Query( $args );

---

8. Folder Structure Matters

Don't dump 5,000 lines of code into functions.php or a single plugin file. Break it up.

A clean structure looks like this:

/my-plugin
    /assets
        /css
        /js
    /includes
        class-activator.php
        class-loader.php
    /templates
        admin-view.php
    my-plugin.php

Use require_once to load these files from your main file. This keeps your codebase navigational and sane.

---

Summary

Code is poetry, but in WordPress, code is infrastructure. Write it to last.

1. Prefix your functions.
2. Sanitize inputs / Escape outputs.
3. Use Nonces.
4. Follow proper indentation.

Your future self (and your clients) will thank you.