Best Practices – Part 1

I am in the middle of Matthew Weier O'Phinney and Lorna Jane Mitchell's talk on PHP Best Practices and after the 3 pages of notes I took in the first hour I wanted to get some things down on virtual paper before getting too far into it.  There is a lot of information that they're giving out.

Source Control

The first thing they talked about was Source Control.  Unfortunately, I was doing my writeup on MongoDB and I missed a bunch of stuff.  That said, there were two things that I had time to write down.

The first thing was "If you are not using Source Control, START!"  I have to agree.  It'd be silly if I disagreed.  The only real question is which source control to use. For that there was a list provided from Wikipedia that gave a comparison of different version control systems that looked pretty useful.

Coding Standards

The next section that they started talking about was that of Coding Standards.  There are a few ways that you can know if you don't have a coding standard.

1. You reformat it
2. Code you wrote 6 months ago looks different from today
3. Modifying old code introduces syntax errors

When trying to determine whether or not you need a coding standard ask your self the following questions.

1. Can you read your own code
2. Can others read your code
3. Can you read someone else’s code
4. Can you switch between code bases easily

Coding standards assist in the maintainability and collaboratibity of your code.  What this means is that you can have more people working on your code.  Code is structured predictably.  When something is predictable it is easier to have someone new work on your code.  Coding standards decentralize who can work on code.  In other words, when you're on vacation and you don't want to be bothered by some emergency code change that needs to be done you can simply pass it off to someone else who can get working on it faster than you can get to a computer.  And really, after having several umbrella drinks on a Caribbean beach somewhere, would people really want you working on code?

One of the statements  I really appreciated was the statement; "Don’t write your own coding standards!!!  There is nothing special about your code."  When I was working in Zend's Services department I would work hard to encourage customers to embrace some kind of coding standard.  I didn't care which, but they had to chose one.  OK, well, that's not entirely correct.  I told them to use the Zend Framework coding standards because they have already born themselves out in the real world.  But the Zend Framework coding standards were no different from the PEAR coding standards (which ZF stole from) which was no different from the Horde standards (which PEAR stole from).  In other words, the problems that people were trying to solve did not change.  There were some updates made to handle some new cases, but for the most part, the coding standards have been relatively static.

Design Patterns

Design Patterns for me are a bit of a double edged sword.  On one hand they solve a very useful purpose.  They provide common solutions to common problems.  The problem is that there are so many problems that need to be solved that there are, in my mind, too many design patterns.  In other words, because there are so many potential gloves to fit the hand people sometimes worry too much about getting the exact right design pattern.

That said, Design Patterns have a great use if you don't become too overburdened by them.  Lorna did a great job about describing some of the more pertinent.  but she also said something important; "don't invent reasons to use design patterns".

Factory

• Has methods to create and return objects
• May return different objects
• May use complex logic to work out the returned object

Registry

• Can be a singleton but not a requirement
• Register them here but access them elsewhere

Adapter

• “Adapts” a specific interface to fit something else
• Allows the class wrapped by the adapter to exist independently from the component

Root cause analysis – Client got a bit of knowledge!

Decorator

• Wraps another class in order to modify its behavior
• Target class doesn’t change
• Decorating class often implements the same interface
• Can be visually decorative, but not always

This one was the most interesting to me because you don't see it much in PHP applications, but the example that Lorna showed looked eerily similar to Swing layouts.  The example looked something like this.

interface LabelIterface
{
    public function render();
}

class LabelNewLineDecorator extends BasicLabel
{
    public function render()
    {
        return $this->labout->render() . "n";
    }
}
class LabelStarDecorator extends BasicLabel
{
    public function render()
    {
        return '** ' . $this->labout->render();
    }
}
class LabelHyphenDecorator extends BasicLabel
{
    public function render()
    {
        return str_replace(' ', '-', $this->labout->render());
    }
}

You have some basic functionality, but it is easily extendable.  It "decorates" the original class.  Neat.

Observer

• Watches for changes in another object
• Responds to those changes
• Target class is aware, notifies observers

I was thinking about this and this sounds a lot like the Zend Framework plugin and action helper functionality. 

Matthew and Lorna are getting up and running again so this is where I'll stop.  Nevertheless, I made a really good call in attending the Best Practices talk.