On the Exakat.io blog there's a post continuing on from a "dos and donts" article about programmer practices. In this new post cover some of the rules in a bit more detail from the original article.

Last week, I ran into ‘PHP Dos and Don’ts aka Programmers I Don’t Like‘ on reddit’s PHP group. It features a list of 11 points that the author hates finding in PHP code. [...] The most interesting point is that coding references are used to asses code. They may very well be automated, thanks to static analysis. I thought it was a good challenge for Exakat.

The list covers several of the rules in the list, providing a brief explanation (and a bit of how it relates back to PHP) including:

• Unnecessary casting
• Extra bracket and braces
• Lack of coding standard
• Too many nested if statements

He ends the post with a bit of detail about how the Exakat service is checking for these "failures" in it's newer "RadwellCode" report. He even gives the scores of some of the more well-known and used PHP projects including the Zend Framework (v1.12), WordPress, Composer and even Exakat itself.

James Fuller has a new post to his blog today about a way you can enforce contracts in your PHP using a combination of type hinting and value checking.

Design by contract is an important concept for controlling what type of input your methods or functions can receive. One of the most dangerous features of PHP is that functions will still execute even when they are missing required arguments, by emitting a warning instead of an error. In this post, I am going to walk through some of the solutions available to deal with this problem.

He shows how to alter a basic function to first use type hinting to catch when a variable is the wrong type (in this case checking for an array and stdClass) which causes a Fatal error and makes the function not execute. He includes sample code for the type/value checking option and also includes a suggestion of using PHPUnit's assertions as another option.

Finally, he introduces the ContractLib tool (from Stuart Herbert) that makes use of closures to enforce checks - his example checks to see if something is a string and that it's not empty.

New on the ServerGrove blog today is a quick post talking about how you can enforce key constraints on a MongoDb with Doctrine in Symfony.

Of course you can define unique indexes to prevent duplicate values and there are a couple of different syntax options to do so, which are clearly defined in the official documentation. But defining and creating the indexes is not enough. You must specify when you want to enforce the constrain, this is due to the fact that the PHP driver needs to tell MongoDB to throw an error when a duplicate key is found.

The fix is as simple as adding a "safe" option to the "flush()" call on your database object. If you give it a value of "true", the ORM is smart enough to handle things on its own.

In a new post to his blog Klaus Graefensteiner takes a look at a quick way you can enforce your set of coding standards right inside of the Eclipse IDE with the PDT extension installed. It's not the easiest thing to do, but if you have a well-defined coding standard and know you'll be enforcing it strongly, this might be the way to go.

I recently came across a nice collection of coding standards that the developers at Gallery2.org are using. I especially liked the summary of settings for Eclipse PDT. I applied them to my Eclipse PDT development environment, took some screenshots and put this article together for my personal reference:

Settings he changes include some of the general editor settings (like tab width and margins) as well as PHP and source control specific settings to remove extensions the IDE doesn't need to worry about. He also mentions the "Code Templates" feature that allow you to get more specific and define the standards at the code level, not just the editor.

Markus Wolff takes a look at a part of the setup surrounding the Zend Framework in this blog post today - the Framework's CLA.

Contributors to the Zend Framework must first sign a Contributor License Agreement (CLA) before they're allowed to commit anything. This is claimed to make the Zend Framework "IP clean", so big corporations have no problem adopting it.

I've never believed in this proclaimed need of being "IP clean". Maybe that's because stealing someone's proprietary code never came to mind - am I just to good a person? However, in a world where in certain strange countries (I won't drop any names here) you can actually patent software - or worse, ideas - it is increasingly difficult to write a single line of code that you can be sure of not violating anyone else's so-called intellectual property.

He quotes from the CLA's FAQ on the Framework site about the protection this CLA offers to both the Framework and to the developers that contribute to it.

His rebuttal is one of "how can this be enforced?", which, of course, he realizes is just not possible. He casts a "marketing first" light on the CLA, suggesting that it's just a way to help sell it to corporations.

Markus Wolff takes a look at a part of the setup surrounding the Zend Framework in this blog post today - the Framework's CLA.

Contributors to the Zend Framework must first sign a Contributor License Agreement (CLA) before they're allowed to commit anything. This is claimed to make the Zend Framework "IP clean", so big corporations have no problem adopting it.

I've never believed in this proclaimed need of being "IP clean". Maybe that's because stealing someone's proprietary code never came to mind - am I just to good a person? However, in a world where in certain strange countries (I won't drop any names here) you can actually patent software - or worse, ideas - it is increasingly difficult to write a single line of code that you can be sure of not violating anyone else's so-called intellectual property.

He quotes from the CLA's FAQ on the Framework site about the protection this CLA offers to both the Framework and to the developers that contribute to it.

His rebuttal is one of "how can this be enforced?", which, of course, he realizes is just not possible. He casts a "marketing first" light on the CLA, suggesting that it's just a way to help sell it to corporations.

DevShed is continuing their "Enforcing Object Types in PHP" series with this new tutorial today. This time, they're focusing mor eon the use of the instanceof operator in PHP5.

This three-part series goes through the basic concepts of object type enforcement in PHP 4/PHP 5. It explores different approaches for checking types of objects to help you avoid possible code contamination when objects of incorrect type are inputted within PHP classes.

The end result of this article hopefully will help you to expand your grounding in how to implement object type enforcement in PHP 5, by developing some illustrative, object-oriented examples.

They start with a look at how not to do the object checking but provide a solution to the situation with the help of the instanceof operator. They explain its usage in the context of the widget class they've created, and show you how it can be integrated easily to simplify object validation.

DevShed is continuing their "Enforcing Object Types in PHP" series with this new tutorial today. This time, they're focusing mor eon the use of the instanceof operator in PHP5.

This three-part series goes through the basic concepts of object type enforcement in PHP 4/PHP 5. It explores different approaches for checking types of objects to help you avoid possible code contamination when objects of incorrect type are inputted within PHP classes.

The end result of this article hopefully will help you to expand your grounding in how to implement object type enforcement in PHP 5, by developing some illustrative, object-oriented examples.

They start with a look at how not to do the object checking but provide a solution to the situation with the help of the instanceof operator. They explain its usage in the context of the widget class they've created, and show you how it can be integrated easily to simplify object validation.