0. Underscore instead of Camel Case, just a wordpress rule.
This says a lot about your code, because any good developer reads the standards of the system, and tries to respect them.
This took me a lot to change about my coding style, because I’ve started with CamelCase and already had 2 years of it as a habbit, I still write classes within WordPress using Camel Case, but everything else is underscored, luckily I’ve never used camel case for database variables, so actions and filters were easy to understand accordingly.
I honestly think it’s much easier to read underscore variables than camel case, and even started to like underscore style more over camel case in certain situations.
1. Proper variable naming : naming your variables $x, $y, $z is the worst coding practice.
I am deeply dissapointed by the school system, people use one letter variables way too often, and even in olympic contest people use them, this is the worst thing ever, because the code is unreadable and very hard to manage, I’ve met a lot of “great developers” that have this bad habbit, and even with the best logic, if you’re not properly naming your variables, you’re a bad developer in my opinion, you can code however fast you want, it doesn’t matter, you’ll lose a lot of time yourself if you revisit a code that is for example a few weeks old, and will be confused.
Good variable names are both a combination of short and self-explaining variables, for example $post_id is much better than $id, even in cases when you have a function called get_post, because you could later on possibly add a second optional paramter called $taxonomy_id, which could be optional to reduce the number of queries by one.
2. Always read version release changes.
It’s important to understand that WordPress is constantly evolving, and many things have and will change over time.
The fun part is when something gets deprecated, you need to ensure backward compatability, and also adapt to the latest requirements, but it’s not like you have to do it right away, I think the time allowed to update these things are very good, in the past 3 years I haven’t seen a deprecated parameter, or function to just dissapear overnight, it needed a couple of versions before it was actually gone, I honestly think that, this is very limiting for the core wordpress development in some cases, but it’s the price to be paid in order to not break a quarter of the internet in a single move.
And the great part is when there’s new features, I simply love it, the posibilities and options is what I love about WordPress, and getting even more was like Christmas.
But don’t get too excited just yet, even if it’s a new feature, there are many people who don’t update their wordpress website, almost never.
One feature that I was very happy to see, was the Taxonomy custom metadata, this feature is out there since 4.4, and we’re on 4.6 at the time, storing custom data for certain taxonomies was a pain before, only possible using the wp_options table, or a custom table in certain cases, but I can’t think of many.
I’ve waited a few months before changing WPEP to work using the term_meta new feature, simply because I wanted to give it some time, and see what other developers think about it, and the most important part, allow customers to update to the latest WordPress version.
Even if WPEP has a fallback for older versions, I simply didn’t want to update a perfectly working feature, normally I could’ve just waited and never do it, but I like maintaining things to the latest standards that have taken some time to grow.
3. Use function_exists for third-party functions, always.
I’m not sure if you’re familiar with the time WooCommerce removed a certain function that was displaying cart notifications, but as expert on codeable, it was the day when around 4/5 tasks posted where about “WooCommerce breaking the website”, and the issue was because of badly coded premium / free themes, this could’ve been a non-issue if theme developers would simply use a function_exists, and possibly learn something about dependency injection, because even if it’s not the case in WordPress, it’s a good term to know and understand.
4. Try to implement actions and filters.
It’s very important, especially when someone wants to customize your plugin without modifying the core files, some would say it’s a performance issue, but I for one don’t care about performance as much as I care about maintaining the code and having a flexible system, what’s the point of having the fastest system, if it can’t evolve over time ?
Some important calculation is happening ? Add a filter, but remember, it’s not only the end result that matters, but also the variables in play.
For example : apply_filters( “example_test_score”, $score, $post_id, $user_id ); looks like a good one for me.
Because normally you can grab the $post_id using get_the_ID(), but this isn’t always right. What if the calculation happens in a backend cron job later on ? You want to offer all the important fields from the start, and if other developers fail to use them, it’s their fault, not yours for not offering the right data.
5. And the most important, do your best to respect the wordpress Coding Standards
The wordpress coding standards can be found here, and I suggest you read them weekly and see how much you’ve improved, it takes time to respect them, but if you’re constantly reminding yourself the rules, you’ll start respecting them more often, they’re not set in stone, but they’re a good thing to follow, I personally agree on most of them, except for a few ones that just won’t cut it in my coding style, especially the Yoda Conditions, which I don’t like right now, maybe I will later, hopefully.
Debian Linux had a 0 day vulnerability which could’ve been easily spotted if Yoda Conditions would’ve been used.
if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
retval = -EINVAL
Specifically the part : current->uid = 0, which should’ve used == instead of =, this caused the variable to be changed, instead of actually being checked.
If you want to read more about this, feel free to google Debian Linux Yoda Conditions 0 Day, and you’ll find multiple great articles.
Thank you for reading this, and if you have any questions, please feel free to leave a comment, I’m checking comments daily and approving non-spammy ones.