Tag archive: debugging

Yoda conditions

Because I usually work with WordPress, and because coding standards are a good way of avoiding endless personal decisions that then get in the way of collaborating, I tend to follow the WordPress coding standards. You should too.

Now, there’s something that I’ve noticed when looking at core WP code, which I’d always assumed was some idiosyncrasy that the WP had settled on arbitrarily. It’s where condition expressions are written with the value being tested first, then the variable against which it’s being tested:

if ( 'value' == $var ) { [do stuff...] }

I just thought that was weird, and in the interests of readability I’ve always been doing it the other way around.

Well it turns out there’s a very good reason for this style, and they call it Yoda conditions. The reason is something we’ve all done – typing a single ‘=’ instead of a double one (‘==’). What happens then (with $var = 'value') is that the value is assigned to the variable, and the expression will return the assigned value. So the supposed ‘test’ will always return something equivalent to boolean false, or true, depending on the value (in this case, any string would mean the expression evaluated to true). This can be damnably hard to debug.

So, switching the order means that if you mistype the assignment operator, the mistake will result in an attempt to assign a variable to the value – which isn’t going to happen. So the error is thrown in the right place, and you don’t lose time searching for it.

The weirdness contains wisdom after all.

A little bizarre, it is, to read. Get used to it, you will.

(Credit to the guy from the WordCamp London after party last night! I forgot your name but the tip made it.)

Solving WordPress problems

I periodically get queries about WordPress issues through this site, often in relation to code I’ve posted here. These days I’m usually far too busy to go into deep, free coding consultation; and usually when I do help out I’m just Googling and using the same resources available to everyone.

I totally appreciate that I might have much more experience than some people, and I’ll have a few little hints that could save a lot of time. But sometimes people emailing me seem to be doing something that I fully confess to being guilty of, in the past and even now: shouting out for help too soon instead of stepping back and tackling the problem properly.

So, here’s a little guide I can point people to, partly in lieu of an email reply template. If you’re facing a WordPress coding problem that either looks daunting right from the start, or is driving you insane after hours of trying, the following hints can help a lot.

Read more »

CSS debugging in Internet Explorer

I develop XHTML/CSS primarily in Firefox, followed by testing in tweaks in other browsers. Apart from Firefox being my primary browser anyway, most of the reason for this is that there are some tools for it that have become as essential to me as my text editor (these days, that’s TopStyle). This handy trio are:

  • Firebug – simply incredible
  • Web Developer Toolbar – still very valuable, with some great little features
  • ColorZilla – a good colour picker, plus some things that the others do, but slightly quicker to access

This is all great. However, more often than not, the times when you really need this sort of stuff is in Internet Explorer – especially pre-7 versions.

I’ve not had much luck in IE 6 with the Firebug Lite implementation. I have just come across a good bookmarklet called XRAY. Compared to the Swiss Army Knives above, it’s very basic, but it provides key information about page elements that can really speed debugging along.

Complete archive

Main index