On the CodeDiesel.com blog today Sameer has posted a quick code snippet that lets you see if a numeric array is already ordered correctly (useful for something like unit testing).

I recently wrote a quick code to find if a numeric array is ordered i.e sorted in a ascending or descending order. I needed it to check a sort algorithm I had written. The problem is that the following code has a worst-case running time of O(N).

He includes the forty-five line function that takes in the array and the sort order it should match. The code then loops around through them checking the value against an incrementing local variable. Also included is an example of its use in a unit test, passing it into an assertEquals for a PHPunit test to check the given array.

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.

Johannes Schluter recently looked at one of the new features coming with PHP 5.3 - the goto functionality:

Over the last few days I already mentioned a few hidden gems from PHP 5.3. Now at Christmas I wanted to take a look at some new language feature of the upcoming PHP version: Added "jump label" operator (limited "goto"). (Dmitry, Sara)

No, its not the sort of "goto" you're thinking of - its a bit more limited than that. Johannes mentions that it only allows you to jump within the same execution unit and you can't jump into loops. Used incorrectly, it can be bad but he points out two useful instances - one being a code generator and the other an instance where you might need to drop out of code but not kill off the script in the process (sample code is included for this second one).

Sameer has posted the first article in his "Refactoring" series today - a look at boiling down conditional expressions to only the logic that are really needed (and maybe replacing it all together).

Many times you see a group of conditionals where the returned values are the same. To make the code cleaner you can group the conditionals together using the '&&' or the '||' operators and then extract the code into a separate function. This also has the added benefit that you can reuse the extracted method in other places where the required conditional goes.

He shows how abstracting out a file upload permissions check to another function makes it easier to reuse and simpler to understand (an "if" versus multiple "return" statements).

Using this article from Johannes Schluter as a starting point Vinu Thomas has worked up his own example of how the technique is used in the example on the Launchpad page.

This article is interesting because of the uses which come up when you can create custom Storage Engines using PHP. An interesting usecase for this is in creating test cases, where you can feed the data for a query from PHP and trap the activities on the database.

The example code defines methods for update, write and delete and the SQL to create the table and insert/manipulate rows is included (for a table created with "ENGINE=PHP").

Sameer has posted an introduction to a topic he'll be writing up a series on - refactoring for PHP developers:

In the coming year I'll be starting a series on Refactoring. Refactoring is one of those programming ideas besides Design Patterns and Unit Testing which has made an order of magnitude improvement in my productivity. Although refactoring may not be a 'Silver Bullet' for your programming woes, it is a good tool to add to your mental toolbox.

This initial post defines refactoring, looks at how its different than code optimization and lays out some of his plans for what he'll cover in the series.

Douglas Brown has a few helpful hints to help you write your PHP code defensively, protecting your code from malicious attackers.

The phenomenal growth of PHP applications has also led to a mushrooming of increased quantum of malicious activity. It thus becomes imperative that you write secure PHP code to protect your website. Here are some tips for the same. The three most vulnerable aspects of PHP that can become easily accessible to anyone are XSS (Cross Site Scripting), Global Variables and SQL code.

He details what each is and how you can protect your code against the problems they cause. Some example code is included to give you a better idea of the possible solution.

One of the things that's been hanging around PHP's neck since its early days is the magic_quotes setting that was introduces to try to make things easier. In this interesting post Arpad Ray takes a look at this setting and why its a bad thing for PHP to have around.

Like register_globals, it helped lower the barrier of entry to building a dynamic website by removing some of the complexity. However it certainly wasn't without sacrifice, problems with the implementation quickly appeared and continued to abound for the next ten years. Finally in PHP 5.2.2 we got an implementation which (as far as its intentions went) seemed to be bug free, but of course by then it was turned off by default and was already slated to be dropped in PHP 6.

He looks at a few reasons they're bad (not good enough for escaping, inconsistent, performance issues) and some methods - code snippets - on how to deal with it being turned on on your server.

The NETTUTS.com site has an in-depth tutorial looking at the anatomy of a WordPress plugin:

WordPress is well known for its amazing collection of free plugins. There is one for almost every need you can think of, from backing up your WordPress installation to asking for a cup of coffee or fighting spam. But there are times when none of the available plugins seem to quite do the trick you are looking for. To help you in moments like that, this tutorial will guide you through every step of building a simple, widgetized WordPress plugin with settings.

They break it out into a few sections - the plugin template (files and directories), adding in the first functionality, making the widget for the plugin's output, add in a few settings and you're good to go. You can download the source if you want to dig right in and get going.

In a new post to his blog Eli White looks at something that can be a difficult task at times - interview programmers to find the right fit for your job. HE has one suggestion that could help a good developer stand out from the rest.

I've interviewed my fair share of programmers over the years, and I find personally that how you interview a 'junior' versus 'intermediate' versus a 'senior' programmer needs to change. Specifically in regards to one topic. What's that topic? It's giving a coding test (as well as just whether you ask coding questions in the interview)

He suggests that its especially good for weeding out those for a "junior developer" role showing where they put their emphasis. For a senior role, however, he suggests a test of a different sort - ranking their experience, their history and how much they've publicly done in the community (talks/articles/etc).