Just found this great cheatsheet on twitter by @nickfloyd. Use it wise and be the proud creator of lots of nice clean code! download pdf

Product Details

• Paperback: 487 pages
• Publisher: Apress; 2nd ed. edition (December 20, 2007)
• Language: English
• ISBN-10: 1590599098
• ISBN-13: 978-1590599099
• Product Dimensions: 9.1 x 6.9 x 1.1 inches
• Shipping Weight: 1.8 pounds

Matt Zandstra is one of my favourite voices of the PHP community. He writes in the style most suitable to my taste. Easy to follow, easy to understand with well thought examples and tutorials. He starts everything from the beginning, and drives you through the pros and contras of the given solution. While telling you how to do and why, he doesn't get dogmatic. You'll understand the what-when-why-how of the content and intent. This book is about becoming a senior from a junior PHP developer. Drives you from shotgun surgery and waterfall to TDD and agile. Though the latter two you'll have to find other books, but I'm sure you'd be wanting to. Nice work Matt! :) I've read the Second Edition, but there's a third one released a week ago. If you (and I hope you do) want to read it, you should buy the new edition. (amazon)

Editorial Reviews

Product Description

Backed by a tireless development community, PHP has been a model of language evolution over its 10+ year history. Borne from a contract developer’s pet project, these days you’ll find PHP powering many of the world’s largest web sites, including Yahoo!, Digg, EA Games, and Lycos. PHP Objects, Patterns, and Practice, Second Edition shows you how to meld the power of PHP with the sound enterprise development techniques embraced by professional programmers. Going well beyond the basics of object–oriented development, you’ll learn about advanced topics such as working with static methods and properties, abstract classes, interfaces, design patterns, exception handling, and more. You’ll also be exposed to key tools such as PEAR, CVS, Phing, and phpDocumentor.

What you’ll learn

• Write solid, maintainable code by embracing object–oriented techniques and design patterns.
• Create detailed, versatile documentation using the powerful phpDocumentor automated documentation system.
• Gain new flexibility during the development process by managing your code within a CVS repository and using the Phing build system.
• Capitalize upon the quality code of others by using the PEAR package management solution.

Who is this book for?

PHP developers seeking to embrace sound development techniques such as object–orientation, design patterns, testing, and documentation

About the Author

Matt Zandstra has worked as a Web programmer, consultant and writer for a decade. He has been an object evangelist for most of that time. Matt is the author of SAMS Teach Yourself PHP in 24 Hours (three editions), and contributed to DHTML Unleashed. He has written articles for Linux Magazine and Zend.com. Matt works primarily with PHP, Perl and Java, building online applications. He is an engineer at Yahoo! in London. Matt lives in Brighton with his wife Louise, and two children, Holly and Jake. Because it has been so long since he has had any spare time he only distantly recollects that he runs regularly to offset the effects of his liking for pubs and cafes, and for sitting around reading and writing fiction. Learn more on Matt's website, getInstance.

I've had an interesting talk with one of my friends, who's not really into those magical "useless" crazy stuff we're doing just to get metrics about the "quality" of our code. He explained, that most of the programmers like to think of code as slaves. It needs to be tortured to do exactly what they want it to do. Sure, this is a working approach, but takes a huge amount of energy to regulate the codebase, and prevent it from rebelling. Imagine you're working on a project almost a year or so and everything seems to be going well until some minor changes break the consistence, and bugs start evolving from nowhere. It's like cancer. You fix one cell, two others seem to come. Most of the times the cure is either expensive, or impossible. Shotgun surgery can help, but you'll never want to touch your code again. Familiar? I'm sure that most of the coders in the (at least the www) world are struggling in a huge pile of  Technical Dept - not even knowing what it is.

TechnicalDebt You have a piece of functionality that you need to add to your system. You see two ways to do it, one is quick to do but is messy - you are sure that it will make further changes harder in the future. The other results in a cleaner design, but will take longer to put in place. Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future. The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments. The tricky thing about technical debt, of course, is that unlike money it's impossible to measure effectively. The interest payments hurt a team's productivity, but since we CannotMeasureProductivity, we can't really see the true effect of our technical debt. One thing that is easily missed is that you only make money on your loan by delivering. Following the DesignStaminaHypothesis, you need to deliver before you reach the design payoff line to give you any chance of making a gain on your debt. Even below the line you have to trade-off the value you get from early delivery against the interest payments and principal pay-down that you'll incur. Technical Debt comes in various forms, some of which can be good and some bad - I use the TechnicalDebtQuadrant to describe them. (As far as I can tell, Ward first introduced this concept in an experience report for OOPSLA 1992. It has also been discussed on the wiki.) Martin Fowler @ http://martinfowler.com/bliki/TechnicalDebt.html

The same scenario could be applied to all levels of life. Company management, Governance, etc. People want other peoples working like slaves, without questions, without thoughts, and maximum effectiveness. You wouldn't go working for a company that will treat you like a slave, give you minimal money. But what is so magnetic about working for (let's say) Google? Would you like to work here? Of course you do. There's no sane person in the world who wouldn't like to spend the day in such environment for such salary... But how does this apply to code quality? Code is just like a simple employee in any company. You need to care for your workers, provide them everything you can to make them happy, just as mentally healthy. "But the code doesn't have needs!" - you say, but you're wrong. Of course it can't tell it's needs on it's own, but it has a language of metrics that can come handy. Measure coding standard violations, testability, writing unit-, integration-, end-to-end tests, collecting it's coverage data will get you a full report on the health of your code... trust me, it's worth it. The more healthy your software is, the easier will it be to apply changes to it. (= make the same amount of money, with less effort) Think about it.

If the strip below is familiar, you should consider TDD.

Quick Humor: Programmers day in office | Web Developer Juice.

It's good to see the progress in fellow coders' work. Brandon Savage explains what he had discovered about the Registry Pattern lately.

The Registry Pattern Reexamined

March 26th, 2010 @ 7:00 am Last July, I wrote about the registry pattern and some of its advantages. These advantages include the ability to access objects across different areas of your application, and the storage of objects for later retrieval. Much of the debate in the comments focused on whether or not the registry pattern was suitable for today’s object-oriented development, and some of the arguments focused on whether or not the “global scope” was a good place to have objects. For me, over the last few months, I’ve discovered two reasons why I advise against the Registry Pattern: first and foremost, it discourages unit testing, and secondly, it discourages good design. Unit testing is predicated on the assumption that you are testing small, discrete units of code that do not have dependencies. This requires that developers do everything they can to either remove dependencies or mock them in such a way that the dependencies are neutralized as contributors to the failure of the unit being tested. In PHP 5, objects are not copied when assigned; instead, their address in a hash table is copied. This means that if you retrieve an object from the registry, and then modify it, every subsequent retrieval from the registry will reflect that modification. The reason this creates a significant issue is that it prevents you from testing a discrete unit of code. Now, instead of one thing being the variable in a test failure, there are two: the unit of code being tested and the object it retrieved from the registry. Any time there is more than one possibility for failure, the effectiveness of the unit testing is diminished. As a side note, the same holds true of singletons: modifications to the singleton object will be reflected in every other test performed during that request, thus reducing the efficacy of the unit tests. Secondly, I’ve found that the registry pattern promotes poorer design overall. The reason for this is clear: because you can store an object for later use, there is no need to consider the path through the application that the object might otherwise need to travel. There’s no determination where, when and how to get the object to where it is needed. You can simply pull it from thin air on demand. This leads to developers being lazy about their architecture, and ultimately leads to poorer code (which you can’t determine through tests because the objects keep changing during testing!). Dependency injection forces developers to think about why they’re doing what it is that they’re doing. Moreover, using dependency injection means that you’re more likely to employ good development practices like abstraction, composition over inheritance, etc. The reason for this is because as a developer, when you start injecting three or four or five objects, you begin to consider why; this often leads to a refactoring, and ultimately a better finished product. As I stated before, design patterns are not the problem, and each design pattern has an important reason for existing and solves a very real problem. The registry pattern shouldn’t be forbidden or never practiced, but it should be practiced sparingly, along with all other design patterns, because it isn’t a one-size fits all solution. The original work of Brandon Savage.

A good writing about the solution to this problem describes the Dependency Inversion Principle one of the 5 SOLID development principles is on Giorgio Sironi's blog, you should consider saving in your reader.

High level classes should not depend on low level classes. Both should depend upon abstractions. Details should depend upon abstractions. Abstractions should not depend upon details.

Read the solution on Invisible To The Eye >>>

The title is a bit wishful thinking, but you'll see why. The guides below could be used for any PHP project out there, but it will represent different things for different quality code.

This tutorial doesn't handle UI testing. You probably have a lot of code sitting on your hard drive and hopefully you already use some sort of source control system. The trouble is, that whenever you have to fix a bug, you can only be sure, that the specified bug is gone, but you're unaware of what might have broken. This tutorial assumes you know what OOP is and you use it more-or-less for your projects. In an ideal world you develop a web application, users use it and everybody is 'appy. But we (at least I) don't live in an ideal world, money doesn't come with spam. (wish it would). Did you ever get into a situation of working way more for the same amount of money, because bugfixing took twice as much time as creating the software? I did. The 2day coding resulted 2 weeks of bugfixing. Why? - you may ask. Every single bug I've fixed, introduced a new one somewhere else. That was the point that led me to the world of eXtreme programming.

Read the rest of this post »

Continuing the post Validators - the beginning This post is about age validation. The implementation below let's you easily define a date that will be used as a reference date. Values same or older tan this date will produce the validation to pass, other will not. [cc lines="-1" lang="php" escaped="true"] This implementation assumes that the default validation only * validates for dates 13 years or older. * * @param string $reference The date to refer to. */ public function __construct($reference="-13 years") { $this->_referenceAge = strtotime($reference); } /** * Validates that the given date is earlier or equal than the * reference age * * @param string $date An strtotime capable string * * @return bool true if valid, false otherwise */ public function validate($date) { $val = strtotime($date); return $val_referenceAge; } } ?> [/cc]

unit test

[cc lines="-1" lang="php" escaped="true" theme="blackboard" width="510"] object = new AgeValidator(); } else { $this->object = new AgeValidator($refDate); } $actual = $this->object->validate($value); $this->assertEquals($expected, $actual); } } ?> [/cc]