Quality Assurance on PHP projects - PHPDocumentor

It goes without saying people should document their code so that after a few weeks, months, years they still know what they did initially and why. Besides providing a mental note in the code, it also helps your IDE to figure out what your class is all about, which parameters should be used with the methods and what their return types are.

But theory is not always reality and unfortunately I've come across too many lines of code that were just lines of code, no comments or annotations provided. So, in best cases I could guess the types and parameters, but in many it was too obfuscated. I already talked about usage of a code sniffer like PHP_CodeSniffer in my previous post where you can validate the usage of comments in the code. But forcing developers (using a pre-commit checker) into writing documentation with their code is not really a good thing. Once people are forced in a corner, they tend to figure out ways to escape and your whole idea to deliver better code goes out the window.

As a consultant I face many situations where code is not documented or not documented enough, and the top 5 excuses I always get are:

• writing documentation is not requested by the customer
• no time, too many things need to be done between releases
• too much work, and no one looks at the code anyway
• why should I?
• we charge extra for documentation, but the customer doesn't want to pay it

Like I said, these are mere excuses. I'm not here to judge these people, but I have to emphasize these excuses lack a real fundament to be acceptable in a professional environment. Maybe I'm taking to much pride in my "craft" as PHP developer, but don't you want to offer your customers the best you're company can provide?

Let's turn things around and imagine a new developer joins your team. Wouldn't it be great if you had documentation that could create complete documentation on the source code so it's easy to get into the flow of things? And when looking at the code in their favorite IDE whenever they access existing code, wouldn't it be great they could see instantly what parameters are used for a certain method or function with a brief explanation why it's useful? Maybe that's why I consider writing documentation part of writing code, invalidating all 5 excuses mentioned earlier.

Documentation 101

Writing documentation alongside your code is really not that much of work when you think of it. For all classes, you probably have a template that you can use that details your library of code components.

<?php
/**
 * My Awesome Library
 *
 * This library provides additional functionality and resources
 * for our standard framework [fill in your favorite framework]
 *
 * @category My
 * @license Copyright 2011 © My Company, Inc. - All rights reserved
 */

When you actually write your class components, just explain in short what they do and why they've been created.

/**
 * My_Amazing_Component_Class
 *
 * This class provides amazing functionality that extends the framework
 * that's being used by this company.
 *
 * @package My_Amazing
 * @subpackage My_Amazing_Component
 * @version $Id:$
 */
class My_Amazing_Component_Class
{
}

Once you get to the point where you write the method, you only need to provide some additional information about what it does, what the parameters are, the return types and if they throw exceptions or not

/**
 * We need to take two parameters to figure out which is the location
 * that we want to display on the map.
 *
 * @param float $latitude The latitude of the spot
 * @param float $longitude The longitude of the spot
 * @return string The link that displays the spot on a map
 * @throws OutOfBoundsException When values are invalid
 */
public function findTheSpot($latitude, $longitude)
{
}

As you can see, not really difficult to get the documentation in place and when you do it immediately you don't even waste too much time writing it.

Automated API documentation

If you have the documentation in place, there are tools out there that allow to generate API documentation quickly and easily. There are less known but very promising tools like Doxygen, DocBlox, phpdocgen and many more. But the most known is still PHPDocumentor. The tools that were mentioned here all have their pros and cons, but their usage is pretty simple and their outcome is exactly what you need to have good documentation of your source code.

PHPDocumentor is easy to use and requires just a couple of parameters to generate high quality API documentation.

user@server $: phpdoc \
  -o HTML:frames:earthli \
  -ric docs/README.txt \
  -ti "PHPDocumentor Example" \
  -dc MyCompany \
  -dn My_Amazing \
  -d application/models,application/forms,library/My \
  -i *.phtml \
  -t docs/api

Options used here:

• -o HTML:frames:earthli defines the template to use, in this example we use the framed earthly HTML template
• -ric docs/README.txt defines the README, INSTALL and CHANGELOG files
• -ti "PHPDocumentor Example" provides the title
• -dc MyCompany sets the default category if no category is being provided
• -dn My_Amazing sets the default package if no package is being provided
• -d application/models,application/forms,library/My defines the directories that contain the php code you want to document
• -i *.phtml defines files that should be ignored when rendering
• -t docs/api defines the location where the API should be generated

Running it on command line will look more or less like this

The result of it is that you get very nice documentation that can be handed out to all developers on your team, third party service providers building on top of your applications or new people on your team.

As you can see, isn't it great to have documentation with your code that requires not much of additional work? Don't forget, it's not just great to create smashing API documents, but it also helps your IDE as it will be able to give your more detail what kind of parameters and methods your classes provide and need.