Life Lessons Reinforced By WordPress Coding Standards

Above all else, create code that is readable, meaningful, consistent, and beautiful.

— WordPress Coding Standards 

Lanyards printed with Code is PoetryRecently I attended WordCamp Portland 2017, where Shawn Hooper and Doug Yuen discussed best coding practices in WordPress and plugin code. Not being a coder, I hadn’t realized how good programmers strive for clarity, understanding and efficiency just like technical and fiction writers do, trying to make life better for everyone reading and executing code.

Here are a few best coding practices Shawn and Doug discussed, and how I think they apply to life as well.

Use ALT tags for all images

Allows visually-challenged readers to know what images are associated with the text. Essential to building accessible code and websites.

Recognize there are multiple ways of perceiving the world. Help others see what you see. You never know who’s going to be affected by your communication.

Comment your code

Explains why some code is structured a certain way, or what it’s supposed to do.

Be kind to your future self. When you can’t remember why you did what you did, you can go back and find out. Keep a journal about the important decisions you make so you don’t have to doubt yourself later.

Use tabs at the beginning of the line for indentation; use spaces mid-line for alignment.

Enhances readability no matter what client or browser is used to read the code.

Sometimes things that seem silly or petty are actually there for a good reason. On the other hand, don’t sweat the small stuff. Make a decision and stick to it. Keep it simple and sensible. Don’t write something that will make you later press the delete key many more times than necessary.

Always use full PHP tags. Never use shorthand PHP start tags.

Ensures clarity and sets expectations.

Clarity trumps cleverness. Just tell the rest of us what the heck you mean. The digital equivalent of using your turn signal. Write in full sentences, not emojis.

Remove Trailing Spaces

Trailing spaces are sloppy, screw up your output strings, create commit noise, make the parser skip extra characters while compiling, and bloat file size unnecessarily.

Closure is good. Clean up after yourself. Don’t add to the chaos. Clean up your own messes and mistakes.

Avoid touching the database directly.

(Always a good idea.) Database abstraction (using functions instead of queries) helps keep your code forward-compatible and, in cases where results are cached in memory, it can be many times faster.

If you have to make a change to something, try to do it in the least invasive way possible, that gives you the most latitude in the future. Don’t screw with what you don’t understand. If it ain’t broke, don’t fix it. On the other hand, if you gotta change something, don’t be afraid to commit…but make a backup first. Step lightly.

Have ternary operators test if statements are true, not false.

Readers don’t have to jump through mental logic hoops.

It’s better to assume that people’s statements are generally true, that they have good intentions, and that the universe is mostly a welcoming, supportive, and abundant place to be. Keep the faith. “Trust in God, but tie your CamelCase.” Testing for false statements — catching someone in a lie — can be good in the end, but it can also piss generally truthful people off, especially if they are telling a white lie with good intentions.

Use Yoda Conditions

if ( true == $the_force ) {

    $victorious = you_will( $be );

}

When doing logical comparisons involving variables, always put the variable, or r-value, on the right side and put constants, literals, or function calls, or l-values, on the left side.

In life, try to determine what is passing and impermanent, and what is core and lasting. Put what’s core and lasting first. My former CEO used to talk about “crystal moments,” which happen only a few times in a lifetime (such as a child’s wedding), and “rubber moments,” which “bounce back” along our lifelines and give us repeated opportunities for experience (such as a kid’s softball practice).

Declare Variables With var

Each function should declare any local variables necessary. Otherwise, a variable can leak into an outer scope and can unwittingly refer to and modify that data.

If something is variable, changing or uncertain, declare what it means to you. ASSUME makes an ASS out of U and ME. There are (at least) two sides to every story; everything can be taken more than one way. Strive to be clear. If something can be taken in a way different from what you intended, it will be. If something *can* blow out of the back of a boat on a trailer, it *will* blow out of the back of the boat on the trailer.

Part of being a good steward to a successful project is realizing that writing code for yourself is a Bad Idea™. If thousands of people are using your code, then write your code for maximum clarity, not your personal preference of how to get clever within the spec.

— Idan Gazit

Comments are closed.

Powered by WordPress.com.

Up ↑

%d bloggers like this: