onekay

My copy of php|arch’s Zend PHP 5 Certification Guide by Davey Shafik/Ben Ramsay arrived yesterday, which rather means I should get around to booking the test. The book itself does an excellent job of covering PHP’s many nuances, and would (IMO) be a good guide for any competant programmers using PHP for the first time. I brought the book to make sure that my knowledge was sufficient to take the test before I spent $125 on the voucher, with the intention of ebaying the book once I’d finished, however, having read most of the book last night, I think it would be a good addition to my bookshelf, especially to lend to other developers on my team.

The book is essentially divided into the different subjects that the Zend exam tests: Basics, Functions, Arrays etc, up to Streams, Security and XML & Webservices. Each is presented in bitesized chapters that concisely cover the subject matter, rather than providing an in depth view. Things get a little wierd when database programming is covered, as no PHP is really discussed in this chapter but a rudimentary knowledge of SQL is required for most people writting PHP so it makes sence to cover the subject. Throughout the book there are information points which contain tidbits of advice about the subject - which I assume are things which might not be tested directly in the exam, but are handy things to know, these are pretty neat.

My only real complaint is that the book spine is printed upside down. Seriously though - if you’re studying for the exam, or at least just thinking about taking it and want to make sure that your knoweledge of PHP is sufficient, or you’re already a competant developer, but you’re thinking of dabbling in PHP and want a quick guide to the syntax and nuances of the language, then this would be a great place to start.

There have been a few blog posts floating around about a talk Tim Bray delivered at the International PHP Conference 2006. I wasn’t at the conference, nor have I heard the talk or seen slides, I’ve just read what Tobias Schlitt said about it. The other day Jeff Moore raised an interesting question - Why is PHP Code Considered Hard to Maintain?

Jeff suggests that its not PHP itself that is hard to maintain, but the programs that make it so popular, wordpress, phpMyAdmin, phpBB… those sort of things, and to a certian extent I agree. Some of the most popular php programs are a mess, and would be hard to maintain, PHP does make it easy to write code that is hard to maintain. Thats not to say it makes it hard to code ‘easy-to-maintain’ code, just that it can be easy to write sloppy PHP.

Writing maintanable code takes a degree of disipline, but it isn’t hard and it certianly has its rewards.

• Have coding standards. And stick to them. Every developer has thier own preferences, but reach a compromise with everyone on the team and agree on a set of standards that will help you keep all your code looking similar. It should be easy to scan, and will look neat. There are plenty of places to start - take a look at the PEAR standards as a starting point for your project. Dont be a nazi about your coding standards though concentrate on keeping code readable rather than strictly adhering to the standards doc.
• Organize your files. Firstly keep anything that isn’t supposed to be reached through a URL out of the webroot - templates, include files, configs, class files, log files, backups, cron scripts etc. This stuff shouldn’t be browsable. You can hide it in folders with ‘Deny from all’ directives in a .htaccess file - but its better to sit it below the webroot.Then look at your web visible file structure - put images in img/, stylesheets in styles/ and so on. Once your web visible structure is in order, then think about what you have below your webroot.Your filename conventions are also important. I normally start each class with a capital letter - so files like Template.php and Model_Abstract.class are classes, anything else is normally lowercase, underscore separated and with an extra extension if they are included files: main_header.tpl.php, global.inc.php, default_style.css default_style_print.css
• Separate your presentation logic from your page logic. Everyone says do this, but no one really explains _why_ you should do it. Separating these things allows you to re-use your presentation code elsewhere. It means your designers can play with the design _without_ ever breaking the application behind it. Remember that separation of code isn’t the same as separation of logic, for instance, alternating table row colours is presentation logic, and should be done in that layer, while checking users are logged in and have access to the specific page is page logic, and shouldn’t be done in the display layer. Savant is an excellent place to start.

• Use less code. This is obvious - the less code you write, the less you have to maintain. Re-use code wherever you can, and dont write anything you dont need. Refactor code as you go to make it as streamlined as possible. Remember to remove redundant code too.

• Documentation. Documentation. Documentation. These have got to be the three most important things to remember when it comes to maintainable code. Document your code as you write it - explain what everything does and why you’re doing it that way. This will help when you, or someone else comes to revisit the code in six months time and has to work out what it does. As a rule of thumb document anything that you can’t understand with a quick glance.You should try and comment all variable declarations, especially if the name doesn’t describe the variable too well.Each file should contain a file level docblock describing the use of the file, If a script takes _GET parameters or ARGV arguments (command line) a docblock containing a usage example should be written in the file level docblock. A usage example should be given for any classes that are not normally initiated using the constructor (eg factory classes)

  Comment on numeric data, if a number represents a length or distance, comment what units it is in (meters, miles, hours etc.)
  Comments should be used to identify missing functionality or unresolved (known) issues in the code. PHPDoc has a @todo tag specifically for this. If a block of code is commented, an explanation should be given for why it is commented, and by whom - even if it is just a temporary hack.

• Obey the OO principles you learnt at school. Encapsulate what varies, use inheritance but favour composition, depend on abstractions not concrete implementations, strive for loosly coupled objects, program to an interface not an implementation, keep classes open for extension, closed for modification yadda yadda yadda. There are enough resources online about this stuff

There you go - you have a codebase that you can come back to at any time and understand - or let a competent developer loose upon without being hugely embarrassed. \o/

Justin Silverton has a list up of his top 5 PHP tools and the comments on his page are quite disparaging.

I thought I’d just drop my current favourite 5 PHP tools.

• XDebug is an awesome PECL extension which gives you a bunch of debugging and profile tools - it takes a lot less setup than PHP for Eclipse or the ZDE debugger/profiler too

• Waterproof Softwares phpCodeBeautifier is pretty handy for tidying up that incredibly messy code you’ve just inherited.

• My choice of (nearly) free windows text editor goes to Edit+, which is pretty neat for all sorts of code stuff - it has regex support too which is neat. For the most part I use the Zend Development Environment though.

• Savant is one of the most sensible PHP templating systems availiable - as it uses PHP as a templating language, instead of some ugly pseudo code PoS. Its pretty lightweight, and distributed as a PEAR package. It’s even being reworked for PHP5 now too.

• My final PHP tool is written in Python. Trac is just about the best issue tracking/wiki/project management/repository browsing tool availiable. If you havent moved to Subversion yet - then Horde’s Chora project is an acceptable repository browser, but doesn’t have half the neat stuff trac has.

Hope these tools help you as much as they have helped me

At webgains we’re finally making the move from CVS to Subversion now and it seems to have a whole lot of benefits with it - cheap (time and space) branching is by far the biggest improvement - suddenly merging branches doesn’t seem like such a daunting task anymore. This move comes at a time when we’re preparing the system for internationalisation, so having a smoother version control (and with it, better deployment management) is going to be a big help.

There are a number of things you can do with your version control to make sure that your teams development and deployment goes as smoothly as possible:

Keep a stable release branch, and work on an unstable trunk
If your developers can commit to the trunk, without fear of messing up the live system, then they will be able to commit more often. If they can commit more often thier work is backed up to the repository, and the team will have to deal with less conflicts. If you have a stable build of the site/software on a branch, then you can merge the selected changes to it in order to do a release, rather than upload the bleeding edge trunk straight to the live system.

Have a staging ‘test’ area to test a release before it is put on the stable branch.
This means keeping a copy of your software or site somewhere that people dont make changes to - its not a sandbox development area, its a test environment as close as you can get to the live system where you can test and benchmark your stuff before the code goes live.

Review code before it is commited to the testing branch
Once the code is in a testing or live environment, its too late to refactor or rewrite code, so a code review isn’t all that useful here. Review _before_ it is merged to the live or testing branch, because this is the best opportunity you have before its sitting on a live website being tested for real. Dont look at code reviews as a huge formal organisational administrative thing that you’d love to have the time in your team to do - it doesn’t need to be more than another developer looking through the code, making some notes and informally talking through it with the coder.

Have a release number
It can seem strange to have release numbers for an in house website or other similar projects, where there is no distributed application, and it can be difficult to apply some of the principles of software engineering to a project like that - it tends to grow organically and features and bugs are introduced on an ad hoc basis. This isn’t always a bad thing, but the bigger your project becomes, and the more developers you have working on it - the harder it will be to manage well. Having a release or version number makes a website build/maintanance seem a bit more like a software development - and makes it easier to see how to apply software engineering principles (like version control, code reviews, unit testing and software modelling) to your project.

Obviously these all take a bit of dicipline and hard work, but thats what being a good developer is all about.

I’m pretty excited about this release, there is bunch of stuff that I want to get my hands on (the Filter extention and the DateTime objects being noteworthy) but probably the most immediate change of importance to me is the fix to the magical __toString() method.

Up till 5.2 __toString() was only called when the object was sent to echo or a print() - now you can throw the object around anywhere that would cast the object to a string, and have it call the __toString() method:

[code]
// concatenation
$string = ‘foo’.$barObject;

// casting
$string = (string) $object;

// functions & language constructs
// which take strings as arguments
try
{
$foo = new Foo();
echo htmlentities($foo);
}
catch (FooException $e)
{
die($e);
}
[/code]

even the echo shortcut should work!

Thanks guys - and keep up the hard work!