We’re always on the hunt for talented LAMP developers and as a consequence we end up evaluating a decent amount of fairly diverse PHP code. We always ask potential employees for a code sample so that we can get a sense of their style and generally make sure they have their heads screwed on right. Because of this, we’ve been evaluating PHP samples from everything from Drupal modules, to batch processing scripts, and even “hardware hacks”.
During this process, one of the issues we’ve had is coming up with an objective rubric to evaluate the relative skill of a PHP developer. Although there are several broad criteria for evaluating code, I’ve been interested in coming up with PHP-centric benchmarks since they’re more directly applicable. Here’s a list of criteria that we’ve been working on to help us identify how familiar an engineer is with PHP.
Negative Signals
Unfortunately, it’s sometimes easier to spot negative signals so here are a few PHP specific “code smells” we’ve identified.
Re-inventing standard library functions
Often, inexperienced engineers won’t search for standard functions that’ll do exactly what they’re looking for. Not always a bad thing but it’s a sign of inexperience. An example would be:
<?php
function getDaysArray(){
$dayOfTheWeek = array("Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday");
$arr = array();
foreach($dayOfTheWeek as $day){
$arr[$day] = $day;
}
}
/** VS. **/
function getDaysArray(){
$dayOfTheWeek = array("Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday");
return array_combine($dayOfTheWeek, $dayOfTheWeek);
}
Not really understanding the ORM (or SQL)
This one isn’t really PHP specific but we’ve noticed it a couple of times anyway. We’ll often see code that looks something like:
<?php
function getActiveUsersOfAge(){
$em = $this->getContainer()->get('doctrine')->getEntityManager();
$users = $em->getRepository("Acme:User")->createQueryBuilder("u")->getQuery()->getResult();
$arr = array();
foreach( $users as $us ){
if( $us->getIsActive() && $us->getBirthdate() < "1991" ){
$arr[] = $us;
}
}
return $arr;
}
As you can see, the code returns all the results and then evaluates the criteria as opposed to passing the selection criteria to the ORM or SQL.
Everything is a global
Due to PHP’s global keyword it’s unfortunately really easy to throw encapsulation to the wind and just make everything a global. Because of that, we’ve seen code that looks like:
<?php
$someListOfData = "";
$someResult = null;
function sumTheList(){
global $someListOfData, $someResult;
// do stuff
}
function writeTheResult {
global $someListOfData, $someResult;
// do some other stuff
}
Positive Signals
What we look for next is usually positive signals that an engineer is generally familiar with PHP. These are generally things you’d pick up after you’ve written a fair amount of PHP.
Has implemented __toString() somewhere
I know this one will be controversial, but my sense is that if an engineer implements __toString() somewhere in PHP they probably have a decent familiarity with the language since its something you have to “seek out”. A canonical example would be something like:
<?php
class User {
private $firstName;
private $lastName;
public function __toString(){
return $this->firstName . " " . $this->lastName;
}
}
Uses output buffering
Output buffering is a bit exotic but it’s indispensable when building web apps without a framework. It also certainly demonstrates a level of familiarity with PHP. A good example would be capturing output from a template and returning it inside some JSON:
<?php
ob_start(function($output){
return json_encode( array("html" => $output) );
});
require "someTemplateFile.html";
ob_end_flush();
Voodoo Positive Signals
Finally, the last couple of things we’ve been looking for are “exotic” techniques that really demonstrate that someone “gets” PHP. Granted, some (most?) of these are bad ideas in production they do convey a certain level of understanding.
Classes that implement the ArrayAccess interface
Since PHP relies so heavily on arrays, building classes that implement the ArrayAccess interface makes them work more naturally in PHP and definitely demonstrates a strong level of familiarity with the language. An example would be:
<?php
class FormInput implements arrayaccess {
private $values = array();
public function __construct($values) {
$this->values = $values;
}
public function offsetSet($offset, $value) {
}
public function offsetExists($offset) {
return isset($this->values[$offset]);
}
public function offsetUnset($offset) {
unset($this->values[$offset]);
}
public function offsetGet($offset) {
return isset($this->values[$offset]) ? htmlentities($this->values[$offset]) : null;
}
}
$form = new FormInput($_REQUEST);
echo $form["username"] . "\n";
Using __set, __get, or __call
Although, using any of these in production is questionable at best, they undeniably do convey a sense that whoever used them knows their way around PHP. An example (from the documentation) would be:
<?php
// From http://www.php.net/manual/en/language.oop5.overloading.php#object.call
class MethodTest
{
public function __call($name, $arguments)
{
// Note: value of $name is case sensitive.
echo "Calling object method '$name' "
. implode(', ', $arguments). "\n";
}
/** As of PHP 5.3.0 */
public static function __callStatic($name, $arguments)
{
// Note: value of $name is case sensitive.
echo "Calling static method '$name' "
. implode(', ', $arguments). "\n";
}
}
$obj = new MethodTest;
$obj->runTest('in object context');
Anyway, like everything I’d take this list with a big grain of salt. We’d also love any input or feedback.
