This is arguably the most critical point of the article. So maybe a project was a one-off and you'll never use the code again. Maybe you will never have to go back and add support for another vendors database product. But guess what: someone else will have to. And, in all likelihood, at some time or another in every programmers career, he will be that "someone". Assembly language programmers can easily relate to this, probably more so than any other developer. Code that is difficult or impossible to understand and extend is often referred to as "write-only" code. This is less common in higher level languages but can still exist. "Write-only" means that the code is so convoluted or complex that without proper comments and documentation, it is impossible to modify or extend in any way. That cool algorithm you wrote with one letter variables names and excessive use of by-reference parameter passing may be a great achievement to you as a developer, but six months later when you need to do the same routine + X, and you pull up the old code and realize it's not documented or maintainable, you get to go back to the drawing board. That cool algorithm just became a pain in the neck.

So, come to terms with it now: you need to document your code. Not only do you need to document your code, but you need to follow a lot of other guidelines to make sure your code is as reusable and maintainable as possible (many of which are discussed throughout this article).

We've talked about maintainability, now let's touch on reusability. Routines are often written as band-aids for a change in application design after development. These band-aid routines tend to be hard coded for a particular task and are often far more complex than the application routines that were in place before, because they are solutions applied to a problem that is outside of their scope. That is, they are applied in a situation where a higher level design change was required. These are the most notoriously difficult routines to maintain. Your day to day routines can also be excessively annoying to reuse, because they were written to perform one particular task in one particular way. The key here is abstraction. If you are writing code for one specific problem, try to analyze the problem at the interface level. "How does this routine talk to the application?" It isn't so much about "What does this routine do?", because you can write a routine capable of just about anything. The key to reuse is to find the level of abstraction at which the routine becomes reusable. You must determine the cost of producing a highly reusable routine when you are patching code, because in the real world, we don't always have time to kick back and refactor an application to suit one or two new features that seem small to the end user and the client.

Conclusion

There are a number of things that contribute to the development of "clean code". How clean your code is can be determined by measuring the efficiency and maintainability of the application code you (or your team) has written and assessing the weak areas of the code. The fewer weak areas of code you find, and the simpler the code is to understand and reuse, the better. Code that is obvious in function (through logically organized, well documented routines and application flow) and easy to maintain (through portability and well planned architecture) is clean code. Writing clean code simply requires that you take the time and effort to plan, document, and organize your projects. As you develop more applications, you will notice that planning and development takes less time and you will be able to reuse more and more code for future projects.

I hope this article will be of use to beginning PHP programmers, and that it will help you grow as a developer!