In this post to his site Brandon Savage talks about "always returning something" from your methods and functions back to the calling script. He also suggests that null is not an option.

A few weeks ago, there was a discussion on Twitter about whether or not a method should always return a value, or whether or not null was a valid value to return. The answer to this question is a resounding no, a null value should never be returned. [...] For example, you check that a file you opened exists, or that a resource performed correctly before using it. But if you receive a null response, how do you test for this The answer is you can't

He notes that a "null" response is not only difficult to test but can lead to ambiguous handling as you're not sure where the error might be. He also includes a snippet of code showing how a null response could break a fluent interface if an instance of "$this" is not returned.

Michael Nitschinger has written up a post looking at avoiding nulls in your applications in favor of a better kind of value handling - the introduction of "Optional" handling.

While every developer has kind of accepted their existence, they are suddenly there when we'd desperately need them to not show up. How often did you writeif($obj === null) in your PHP code? Can't there be a better, more elegant and fault-tolerant solution to the problem?

His solution is to create a PHP version of this "Optional" functionality (via an abstract class) that allows some evaluation of the returned value from method calls on the object. Methods like "isPresent", "getOrElse", "of" and "fromNullable" make it easier to work with null values instead of just the triple-equals checking. He includes not only the code for the classes you'll need to implement it but examples of it in use - an "Optional" abstract class and two child classes, "Present" and "Absent".

Benjamin Eberlei has a new post to his site today answering a question he sometimes gets about using Doctrine2 in a SOLID context (more on SOLID development here) as it seems difficult to follow the Single Responsibility Principle with how the tool is used.

These problems are related to the inability to share behavioral code through aggregation and the complexity of state transformations. Combining both, your average entity with 5-15 fields can end up with hundrets or thousands lines of code. The solutions to both problems boil down to minimizing duplication and maximizing clarity.

He looks at two different kinds of objects Doctrine uses in its setup, the value objects and method objects, and "maximize clarity" on them by dividing them up into more functional-related objects, passed into each other via method injection.

Matt Frost has a new post to his blog talking about reducing complexity and preventing overcomplication in your code and application structure.

We've all come across code that's written so craftily that it takes us some time to figure out what's actually going on in that block of code. We've never written things like that ourselves of course....seriously though, if you're collaborating, not doing things in the simplest terms will create an issue when other people start to look at your code. There is something about us; when we have an opportunity to show off how smart we are; we really try to go for it. The point is that it's not helping anyone and crafty code !== good code.

He makes a few recommendations about how to keep things simple in the various aspects of your development:

• Know your tools
• Know what you're doing
• Check your smells
• Ask "what value does this add?"

By simplifying things, you give others a chance to look at what you are doing and help you understand what you did right and what you can do to improve that section.

In a new post on his blog Timothy Boronczyk has a recommendation for developers working in PHP with databases that have a "fetch object" method - use it correctly or avoid it all together.

Lately I'm finding a lot of instances of the mysql_fetch_object() function being used in a particular codebase I help maintain. Unfortunately, I've yet to see it used correctly. It always seems to be used to retrieve a stdClass object from a query result where mysql_fetch_array() or mysql_fetch_assoc() would be the more appropriate choice.

Most of his complaint is that, despite pulling out the data as an object, most scripts continue to use it like you would an array, looping over it. There's extra overhead generated from the object creation that could cause issues, especially with large return data sets.

The best advice I can offer is to educate yourself and others how the function should be used so its abuse isn't perpetuated. Then, be cautious when using mysql_fetch_object() correctly and understand the process it follows to create and return an object. If not for yourself, then do it for the kittens.

Dan Horrigan has a new post to his blog talking about the value of null - a quick summary about when and where null should be used. Null's a value too, after all...

Let me start off by saying this article is about PHP and PHP alone. Other languages handle this sort of thing differently (and better). In PHP many people (and a few frameworks) return FALSE from methods when the requested value does not exist. However, I am here to tell you that if you do this, you are doing it wrong. Plain and Simple.

In his opinion, "false" is definitely not the same thing as "null" because "null" is technically the absence of a value, not a "not true" value like "false" is. He illustrates with a simple use case of a class that has methods returning various values.

On the CodeForest site there's a recent tutorial that offers a different option for those dealing with an application that has the possibility for rapid change in its database structure - a key/value table in a standard relational database (no, not NoSQL).

Key/value approach in database design could come in handy when we need to store some arbitrary data about another table. For example, we have a users table that holds our user data. Everything is working fine, but some day our client decides that he wants to collect 2 telephone numbers, sex of the user, date of birth... If we try to predefine all the potential wishes of the customer in our table, it would be awkward and our table would grow horizontally beyond reason.

He compares the traditional "users" table with each column a defined type of data against a key/value table where each record holds both the value and a key relating to its contents. While this technique can be flexible, it can also be abused if it gets out of control. Bill Karwin warns in the comments about it and links to two resources on its use.

Chris Roane has a new post to his blog asking an interesting question - should PHP programmers/developers spend the time to go to college?

A common debate in our field is whether or not a college education is worth it when becoming a PHP programmer. People will throw statistics in how much more money you can make with a college degree. But is the cost of college (time + tuition) for a four year degree better than the benefits of having four years of experience in the web programming field?

He qualifies it with the fact that not all college educations are created equal and that it depends on the student as to what they get out of it. He breaks it up into a few different sections with reasoning in each:

• The Benefits of Going to College
• The Cost of Going to College
• The Benefits of a PHP Programmer Not Going to College
• The Negative Aspects of a PHP Programmer Skipping College

On his MontanaProgrammer.com blog Chris Roane looks at the value of a PHP programmer and what you might look for when considering which developers could make the most difference.

Over the years I have come across PHP programmers from different backgrounds. I've seen some do very well, and others fall flat on their faces. One unique element about PHP programmers is that they vary in quality more than most other programming professions.

He mentions traits to consider like speed of coding, reliability, experience, humility and be able to accurately estimate time to finish work. He give the example of three different developers - each with their own skills and experience levels and asks which of these might be the best. The trick is, "best" is very subjective to the needs of the company that wants the code written.

A new version of the Rediska library has been released today, version 0.2.1. Rediska is a PHP client for Redia, a key/value database system (written in C) that's similar to memcache.

It can be used like memcached, in front of a traditional database, or on its own thanks to the fact that the in-memory datasets are not volatile but instead persisted on disk. One of the cool features is that you can store not only strings, but lists and sets supporting atomic operations to push/pop elements.

The library includes multiple server support, content hashing, keys as objects and full Zend Framework integration. You can find out more about the project on its site or just download the latest version.