In a new post to his blog Johannes Schluter recommends that you don't use references in your applications, mostly because of some misconceptions about how they work.

Last year I spoke at eight conferences and attended a few more multiple times at most of them I found myself in discussions about references and PHP as many users seem to have wrong understandings about them. Before going to deep into the subject let's start with a quick reminder what references are and clear some confusion about objects which are "passed by reference."

He re-introduces referenced variables and scratches the surface about the confusion they can cause, not only on the user level but also in the internals of the language, and can lead to some unexpected results. He also mentions the "always passed by reference" idea that several PHPers have about PHP5 objects and why it's not entirely correct. He finishes off the post with a look at returning referenced parameters and how it can lead to bad application design.

In a new post today Jani Hartikainen has pointed out a few errors that developers commonly make when writing and debugging their code.

Back in august, I introduced the error tracking challenge. While it didn't get as much participation as I had hoped for, I did manage to collect some results. In this post, I'll go through the most common ones, and suggest some approaches to avoiding them. Suggest your own errors and tips in the comments!

He's included issues in three major categories - boolean logic errors, typos/omissions and some common debugging mistakes. Inside each are some suggestions to help them make a less frequent appearance in your code: things like splitting up conditionals for readbility/ease of maintenance and being generally more careful in your development to reduce logic and small errors that could be picked up by the simplest syntax check.

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.

If you've ever wanted to go to a technology conference (there's several PHP ones out there!) but have talked yourself away from them with excuses, you might want to check this new post from Lorna Mitchell to see if any of them match up. She dispels some of the common misconceptions about attending conferences - five, to be exact.

I can quite appreciate that different people come to conferences for different reasons, but I cannot accept that people actively avoid conferences because they think its not for them - and the reasons for this, from people who have never been to a conference, are wild and varied. Most are based on misconceptions and I'd like to take the time to examine some of these.

She looks at some of the most common:

• I won't know anyone
• It's too expensive
• My employer won't pay
• I might have to talk to people/strangers
• I haven't been to a conference

These along with a few other recommendations can rid you of some of the worries you might have over attending and maybe give you something new to talk to your manager about when the next conference rolls around.

In a recent post to the ThinkPHP blog Martin Brotzeller looks at a PHP operator that developers should just not use anymore - the suppression operator (@).

The silence operator exists to give programmers an easy way to suppress messages when a command might fail and the code checks for success itself (i.e. in those cases that raise errors instead of throwing exceptions).

He points out a popular use (like putting it on an fopen to prevent it from throwing an E_WARNING) but notes that this could cause trouble if the code is several layers deep and seems to fail silently. He gives en example of the Zend_Loader component of the Zend Framework and how, if the suppression operator was used, errors with an include failed without so much as a blip in the error log. While it seems handy, the suppression operator can cause more harm than good in the long run.

Following up on a previous post looking at characteristics of crappy software, PHPFreaks.com has posted ten more tips - this time, though, they're recommendations about how you can avoid writing crappy code of your own.

Here's their list:

• Learn OOP and common OO principles
• Employ Test Driven Design
• Refactor, refactor, refactor
• Simpler is better
• Use Design Patterns
• Don't Use Design Patterns
• Accept the limitations of your language
• Pretend you are writing a book
• Peer Review
• E_STRICT is your friend
• Create a distinction between "source code" and a "build"

That's right - there's a bonus one thrown in there to help out just a bit more. There's some good tips in there that any developer could benefit from no matter the skill level. They may not all be at your level, but at least they give you something to shoot for.

Davey Shafik has a helpful hint for avoiding one of the worst functions to use in PHP - eval.

There are a shed-load of ways to "eval()" code without actually calling the eval() function '" usually done simply to avoid the use of the dreaded "evil()" function, but often times because the system has eval() disabled using "disable_functions" in php.ini. Here is another simple way to avoid eval() without writing out files to the filesystem

His example uses the streams wrapper to natively execute the code from a string variable as a data element, base64 decoded. It's more of a proof-of-concept than anything else, but its an interesting solution to a tough problem to solve at times.

In this slightly older (Nov 2008) but useful post to Misko's blog, he takes a look at a few common flaws that you should avoid in writing up your code (in any language really).

To keep our code at Google in the best possible shape we provided our software engineers with these constant reminders. Now, we are happy to share them with the world.

Here's the list of the flaws:

• Flaw #1: Constructor does Real Work
• Flaw #2: Digging into Collaborators
• Flaw #3: Brittle Global State & Singletons
• Flaw #4: Class Does Too Much

Each includes some warning signs to keep an eye out for to see if you and your code might be straying the wrong way.

Derick Rethans has posted just a few of the reasons why the "shut-up operator" (the @ symbol) should be avoided at all costs in your PHP applications.

The @-operator is often used to silence errors in noisy PHP functions'"functions that generate warnings that can not be easily prevented. [...] In those cases, there is no way how to check up-front whether the function call will not issue a warning when being called.

There are side effects to using the operator, however, including hiding legitimate errors and making debugging that much more difficult. To back up his point, he includes four other reasons to avoid the operator's use (besides the debugging issues):

• It's slow (part 1)
• It's slow (part 2)
• It's slow (part 3: It generates crappier code)
• Apfelstrudels were harmed (related to the strudel_token in the C code for the operator)

On his blog, Oscar Merida has a quick new post those just starting out with sessions should take a look at. He gives four quick tips of things to watch out for that can help your development process go smoother.

PHP's support for sessions make adding "state" to your web application super easy. Bus because the illusion of state is maintained by storing a Session ID via a user's cookies, you might find yourself losing potentially productive hours chasing down bizarre client side bugs or opening up a potential security hole. Here are 4 tips to help you avoid wasting your time and securing your site.

Items on the list are:

• Don't use underscores in host names
• Commit your sessions before redirects
• Prevent session fixation (great security tip!)
• Don't expose session_id's