In this recent post to his blog Stuart Herbert introduces a system he's created to handle "contracts" in PHP development - ContractLib.

Programming contracts are tests around functions and methods, and they are normally used: to catch any 'bad' data that has been passed into the function or method from the caller, and to catch any 'bad' data generated by the function or method before it can be returned to the caller. These are pre-condition and post-condition tests, and they are tests that either pass or fail.

He points out that by having contracts you not only increase the robustness of your code but you also save time not trying to hunt down data-related issues. Using pre-conditions, you can can check data to ensure things like correct formatting, data that's out of range and data that might be missing. His ContractLib comes with a set of tests that provide good examples of how to use the functionality. Installation instructions are included.

Jeremy Kendall has started up a new blog that's a sort of "WTF in PHP" listing of some of the random (and bad) code that he comes across daily - CSI:PHP.

It all began with a new gig and an amazingly horrific codebase. I began tweeting the most unbelievable, most frustrating snippets I could find. After quite a few of those tweets, Chris Hartjes replied with, "Looking at your tweets I cannot even fathom what your job is. CSI:PHP ?" A concept was born.

Some of the posts so far include eval() hell, a bad use of preg_replace and a bad method for calling mail(). Currently there's not a way for others to contribute their own code WTFs, but from what I hear it's possible for the future.

On NetTuts.com today there's a new (slightly inflammatory) post about why you're a bad PHP programmer - really why some of the practices you follow might be in the "bad things to do" playbook.

We all have our bad habits. In this article, we'll go over a list of bad practices that are worth examining, reevaluating, and correcting immediately.

In his list of things to avoid are suggestions like:

• not planning before coding
• opting for brevity over clarity
• no coding standards
• code duplication
• practicing "Not Invented Here" (NIH)
• not working on side projects to introduce yourself to new technology

Nurul Ferdous has posted his "two cents" on Doctrine - his thoughts on the good and bad things about the popular ORM tool.

What is Doctrine? Doctrine is a popular ORM for PHP which works with RDBMS via PHP objects. This is built inspired by Hibernate from JAVA. This acts as an abstraction layer between PHP and RDBMS.

In his list of good things about Doctrine are things like its hiding of business logic, automatic CRUD, automatic modification of DQL queries, migrations and unit testing interfaces. On his "bad list" are things like not being able to use foreign keys as an identifier, heavy emphasis on an "id" column, not all data types are in DBAL and the SQL constructs missing in DQL. He also includes a scenario where he definitely not use Doctrine - a specific example from a project he just worked on that pushed the limits of the tool.

In this new post to his blog Adam Harvey shares his opinion on unmoderated notes dropped directly into the PHP manual - "they're bad, mkay?"

I've had a couple of whinges on IRC lately about why I'm not thrilled with having user notes in their current form in the PHP manual; we get entirely too many questions in ##php from people who've copied code out of a note and are then annoyed when it turns out the code is wrong, broken, horrible, or all of the above.

His gives an example (one of many currently in the manual) that shows a round-about way of getting a date string that could be done better in a single "format()" function call on a DateTime object.

I don't know what the answer is - moderation has its own problems to do with workload, as PEAR can attest - but a system that's letting that go up as recommended practice (and stay up for a month) has to be looked at.

In a new post to his PHP in Action blog Dagfinn asks the question "is bad code good for you?" He wonders if bad code really is a good thing and how it can be split out from the good parts of your application.

This is an interesting idea that struck me as novel. But after thinking more about it, I believe it's not a radical departure from what we're all implicitly accepting, no matter how fanatical we might be about clean code.

He includes a quote from Luke Welling on the subject talking about how bad code, despite the headaches it may cause for maintenance and future development, can be a good thing if it does good for the project.

Following the release of the Zend Simple Cloud API for their Zend Framework, Clay Lovess has pointed out that sometimes a simple cloud could be a "dark cloud" for your application.

Developing "cloud-native" applications? Soon there'll be an abstraction layer for that too. [...] Sounds great, right? Not so much. As Chief Architect of a PHP-based "cloud-native" application that's handling hundreds of millions of requests per month, there's no way I'd consider using Simple Cloud. Here are five reasons why you shouldn't either.

His reasons are pretty simple ones - leaky abstractions, lowest common denominator calls the shots, the important groups (leaders) don't always get involved, creating a native option isn't that hard and, face it, you'll never make the move over because of the work level and uncertainty involved.

If you'd like to find out more about what he's talking about, check out this site for more information on Simple Cloud.

Samuel Folkes has posted a few practices (seventeen, to be exact) that PHP developers should "banish forever" from their development habits.

The following is a list of 17 PHP programming practices that in my opinion should be banished into oblivion. Forever and ever. Amen. Please note that this list is in no particular order.

Some of the practices include:

• Relying on Magic Quotes
• Mixing HTML, PHP, SQL, JS, CSS, Etc, Etc
• Not Documenting Code
• Using Regex Functions for Basic String Manipulation.
• Unquoted Array Keys
• Using Uninitialized Variables

There's lots more where those came from so check out the rest of the list here.

Jeremy Zawodny has shared his opinion on database abstraction layers in PHP applications - they need to die.

Beware of men preaching of false hope. Take, for example, the way some folks feel like they need a database abstraction layer in their applications. [...] So why do folks do it? Because PHP is also a programming language and they feel the need to "dumb it down" or insulate themselves (or others) from the "complexity" of PHP.

He goes on to say that, despite the claims that people make about portability ("it's never that easy") and ease of use, the only real answer is to strip out this layer and use good programming practices to take the database access code out into a separate library that can be replaced quickly and easily.

On the SitePoint PHP blog today Troels Knak-Nielsen has posted some of his own thoughts about the performance tips that Google recently published for PHP.

The project includes an article on "PHP performance tips", which is bordering on being ridiculous. There are of course lots of blog posts with similar nonsense around the web, but since this is being endorsed by Google, it's fair to assume that people might take it at face value. That's unfortunate, as almost none of it is true. The PHP Team responded back with this message, wherein they refute the unfounded nonsense.

He notes that these practices aren't the best road to optimization and, depending on when they might be used, could be harmful to the development of the application. He also recommends XDebug if you really want to get to know where your application is struggling.