Larry Garfield has posted some of his thoughts on return values and reminds you about consistent return types, regardless of the result.

Earlier today, I posted a brief tweet (isn't that redundant?) about return values in PHP (or really, any language). Originally it was about return values from functions (such an exciting topic, I know), but it ended up generating a fair bit of lively conversation, as well as a patch against Drupal 8. So lively, in fact, that I think it deserves more than 140 characters.

He proposes a new rule of thumb: "If your function returns a collection, its null value return must also be a collection." A more broad version of this might be: "make your return types consistent." It's all about predictability and the contracts you have between different parts of your code. If a user calls your method expecting to be able to loop over the results, they'll be disappointed with a "false". He talks some about using and throwing exceptions more effectively for error handling and answers several "but wait..." arguments for his return strategy.

If you've ever been bothered by those pesky NOTICEs when running your code, you know that you can wrap evaluations or check things with an empty or isset call to make them go away. Brandon Savage has a new post that can help you decide which one to use when, though.

As developers, we want to develop code that never emits notices or warnings, and PHP gets a bit antsy when we develop code that utilizes uninitialized variables. Lucky for us, PHP makes it easy to test for these variables without getting these notices. [...] PHP (like most languages) evaluates a logical argument left to right. For an AND condition, both conditions have to be true; PHP stops evaluating if it finds any condition untrue.

He suggests that the case to use isset() is more when you just want to use another check in the conditional but don't want to be bothered if the variable isn't there. A call to empty(), however, also evaluates the contents of the variable if it exists. Be careful, though - empty() returns false if the value of the variable is false - so take care in your use and always test scripts with multiple values.

Felix Geisendorfer has posted two new items to the Debuggable blog looking at suppressing errors in your applications - and no, that doesn't mean using the @ operator either.

As of late I am getting sick of some best practices I have taught myself. Never using the @-error suppressing operator quickly moving to the top of the list. Before you start crying out loud (I know you will), let me say this: I do not mean to encourage anybody to use the @-operator. Applying the practice herein introduced may result in permanent damage to your coding habits and could serve as a gateway behavior to writing shitty code.

He gives an example in the first post of a place where he failed to properly check to ensure an element existed before checking a element of it. The second post provides an interesting solution to the same problem - using empty on the element/subelement to check its existence.

In this new post to his blog, Brian Moon compares two things that, on the outside, might seem a lot alike but do have their differences under the hood - a null value and the isset function.

I am working with a newcomer to PHP and he asked me about setting a variable to null and how to check that. He had found some example or information that showed that setting a varaible equal to null would unset the variable. So, he was unclear if he could then reliably check if the variable was equal to null. Having avoided null like the plague in my years of PHP, I was not sure. So, I mocked up a quick script to see what the states of a variable are in relation to null.

His test verified that a variable, set equal to null will be found to be equal to null, will be set (isset) and will be found empty by PHP's empty

Jani Hartikainen has posted about three simple, but hard to find, mistakes that can cause you endless frustration if you're not looking in the right places.

Here's his list:

• Semicolon after a while - a small problem with big (infinitely looping) consequences)
• empty() and magic __get method - __get will hit first, then empty
• Missing semicolon after break or continue - a classic that can make switches and evaluations difficult to debug

Comments on the post include a few others: working with variables by reference, comparisons with == versus === and strpos finding the first character in a string.

On DevShed today, there's a new tutorial posted looking at two things that can cause headaches for PHP developers (especially when evaluating and comparing values) - nulls and empty strings.

Anyone who has programmed for any length of time has encountered the concepts of null and empty strings. They are not the same, and confusing the two can cause some serious problems. This article deals with these concepts in the context of PHP and MySQL.

They start with a bit of a quiz before getting into how to handle them correctly - making null "safe" and working with it correctly in a MySQL context. SQL statements and table structures are included for their examples.

Brian Moon has a "stupid PHP trick" posted to his blog today - normalizing SimpleXML data you've pulled in from just about any external source.

Anyhow, one annoying thing about SimpleXML has to do with caching. When using web services, we often cache the contents we get back. We were having a problem where we would get an error about a SimpleXML node not existing.

They were using memcache to store the information but came across problems when their code tried to use a (sometimes) empty tag. He gives two solutions - one using a recursive function that identifies the empty items and the other that encodes then decodes the object to and from JSON, keeping the values intact.

The PHP-GTK Community site has a quick new post today showing how to create/empty out a GtkContainer or GtkWindow in your code.

This function provides an easy way to empty a GtkWindow/GtkContainer. I use it when i need to refresh a part of my app by replacing some widgets with others. It can destroy or preserve the child widgets depending on your needs.

They provide both the code itself and a sample usage - a three line script that shows three ways to use it - empty out a container, empty out the container but keep its children intact, and how to use it in the event of a button click.