Jump to content

Checking variables


CyberShot

Recommended Posts

I work a lot with WordPress and I have started to see that they seem to be checking variable backwards from what I am use to. For example.

 

I see this code

$comments_number = get_comments_number();

if ( '1' === $comments_number ) {

       Do something
}

Why are they doing it that way instead of the way I would expect which is

$comments_number = get_comments_number();

if ( $comments_number === '1' ) {

       Do something
}
Link to comment
Share on other sites

Those are Yoda conditions which are supposed to catch programming errors where the assignment operator = has been used instead of the equality operator == or ===. With the normal order, both $x = 1 and $x == 1 are valid, so there's a chance you might miss the mistake. But with the reversed order, 1 = $x is invalid, so you would immediately see the problem.

 

However, I think this has turned into a stupid mannerism. It's hard to read, it tries to solve a problem that barely exists (how often do you mix up = and ===?), and it's just unnecessary when you use a proper IDE which can do those checks for you. If some code conventions demand it, go ahead, otherwise I would avoid it.

Link to comment
Share on other sites

Someone told me an old trick on another forum (He passed away about a year ago) to use === when doing a comparison that way if you accidentally type == it will still work. Very rarely will you have to use == instead of === (or vice versa) and just remember the === operator actually checks to see if the left and right values are equal, and also checks to see if they are of the same variable type (like whether they are both booleans, ints, etc.). The == just cares if both the left and right values are equal. 

Link to comment
Share on other sites

Maybe PHP should introduce the ==== operator. Then we have even more spare equal signs. ::)

 

The primary goal of code should be to clearly express one's intentions, not work around potential typos. Since == and === have entirely different meanings, abusing them as some kind of typo fail-safe is ill-advised and can in fact introduce real errors. You should use == when you actually mean == and === when you mean ===.

 

If you have lots of trouble with typos, use a better IDE or an external code checker. Modern tools can catch even subtle errors, so typos should really be a non-issue by now. Writing unit tests also helps.

Link to comment
Share on other sites

I use Dreamweaver CC as my code editor and I love all the new features it has. I just checked to see if it would catch the mistake of assigning a value is the conditional as Jacques1 suggested and it did. So this "Yoda conditions" to me seems to be irrelevant. I don't like it.

 

Thank you for the information. I have been wondering about this for a while. I never heard of it till now.

Link to comment
Share on other sites

Maybe PHP should introduce the ==== operator. Then we have even more spare equal signs. ::)

 

The primary goal of code should be to clearly express one's intentions, not work around potential typos. Since == and === have entirely different meanings, abusing them as some kind of typo fail-safe is ill-advised and can in fact introduce real errors. You should use == when you actually mean == and === when you mean ===.

 

If you have lots of trouble with typos, use a better IDE or an external code checker. Modern tools can catch even subtle errors, so typos should really be a non-issue by now. Writing unit tests also helps.

Not to harp on it, but my IDE (Netbeans) is always flagging me to use === instead of ==, so it is rare that == should be used. I think the only time I had this come into play (==) is when I was developing an online php calendar and even then it was used very minimal. There are a lot of times a person who is typing on a fly that typing = will be very easy to do. I agree you should use == when should it is actually called for and I don't see many cases where that comes in play. Though using a good IDE is better than using an old trick, but in this case I can't see where this particular old trick will lead a person astray until he or she is better knowledgeable in PHP. I know one instance it actually got me to slow down and think when I saw $row = $stmt->fetch(PDO::FETCH_OBJ) in a while loop and realized that was supposed to be like this when I first started learning PHP. 

Link to comment
Share on other sites

Not to harp on it, but my IDE (Netbeans) is always flagging me to use === instead of ==, so it is rare that == should be used.

 

Then Netbeans is wrong. Those hints should generally be taken with a grain of salt.

 

Weak typing is a core feature of PHP. The entire language is purposely built around the idea that types don't matter that much, so comparisons like

'100' == 100

are very much the norm. The only time you use type-safe comparisons is when you actually need them, mainly in critical components and to check the return value of functions with mixed return types (e. g. strpos() which can both return 0 or false).

 

Of course there are also reasons against weak typing, but if you generally don't like it and find yourself using === all the time, then PHP is the wrong choice. Use a strongly typed language like Ruby or Python.

 

 

 

Though using a good IDE is better than using an old trick, but in this case I can't see where this particular old trick will lead a person astray until he or she is better knowledgeable in PHP.

 

I think Yoda conditions are the last thing I'd recommend to a beginner. Even more experienced programmers struggle with them.

 

 

 

I know one instance it actually got me to slow down and think when I saw $row = $stmt->fetch(PDO::FETCH_OBJ) in a while loop and realized that was supposed to be like this when I first started learning PHP. 

 

The alternative would be to simply avoid those tricks and strive for clarity rather than brevity. If there are never assignments in conditions, then there's no risk of mixing them up with comparisons. Problem solved.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.