PHP Industry Standards
PHP Best Practices
List of PHP best coding practices that can help make your code look more professional and meet established coding standards
Date : 2009-04-13
PHP Best Coding Practices – Industry Coding Standards
PHP has been around for many years now, even a little longer than old Classic ASP. In that time it has really matured as a language. With the addition of OOP concepts and other enterprise level features it definitely has a niche in the web development arena. With this maturing process all the programmers who came ahead of us have helped to identify some best practices to take full advantage of the strengths and help to avoid the weaknesses of the PHP language. Knowing and using these practices is not just a matter of writing better code, although that is an obvious consideration. It can also help you to land jobs.
Because PHP is open-source and “just off Broadway” so to speak compared to Microsoft products there are very few classes and certifications that one could take that would tend to unify the programming methods. One obvious exception is the Zend Certification course. Many people learn PHP from a handful of books and a ton of Google searches. That is a strength of PHP in my book, the one issue to that is that if you're trying to get a job with a development house or a new client it's quite possible that some of your hard learned coding practices might seem amateurish. Some of these coding standards aren't so much about performance as they are about making your code easier to work with, for yourself and for others. Toward that end I want to share a few things anyone can do to make their PHP code look more professional.
Use Classes rather than function libraries. I know that functions actually run slightly faster than class members, but the classes look more professional and make your code look more modern compared to huge files full of functions (so 90's). While we're talking about classes I might mention that classes shouldn't be in libraries either. Use one class per file and don't attach other code to the end of the class, no matter how related it might seem at the time. Either put it in the class, or get it out of that file. There are a number of reasons for this the most obvious being code reuse.
Understand database abstraction layers. Notice I say “Understand”, not necessarily “Use” database abstraction layers. There are arguments for and against these layers. Some say they add complexity and loose performance. I think there are times when the extra complexity is worth it and there are projects small and light enough that it's not really necessary. The point is if you're thrown into a situation where your client is using a database abstraction layer and they believe it is the best practice method then you want to know how they work and what the benefits are. One of the perceived benefits is to centralize the database calls in case there is a problem. If all the database interaction is going through the same code you are much less likely to have one of those sneaky little issues that hides for hours. It can also give the opportunity to add caching and other database wide improvements. Also, if you make a change to the database schema (Oh, please don't do that) you only have to change the code in one place. That being said, I'll leave it up to you to decide if you want to use them in your daily programming.
Document your code well. After many years of programming you can probably read your own code, and maybe most other code as easily as reading a book. It doesn't matter, you still need to add documentation. No matter how easy it is for you to understand the flow and function of your code you need to document so that others can understand it. Imagine the next person to look at that code is going to be a first year PHP developer. What will they need to understand so that they don't break your code? Some times it's the basic code logic that needs documented, especially when management is constantly changing the logic (a pet peeve for another time).
Use full PHP open tags
Initialize your variables. I like to leave error reporting on E_ALL for low level development and testing just so I get the warnings about uninitialized variables. The solution to the problem of uninitialized variables is not to change the error reporting level. This is not just a personal opinion, your code will actually run faster if all your variables are initialized before use. It also makes your code look more professional which can make the difference between getting a project/position or not.
Know different coding standards. There are many different coding standards in use. Freelance developers need to be familiar with as many as possible, and have the flexibility to code to these standards when called upon to do so. My favorite are the in-house standards that seem to make no sense at all. I'm sure after working with them for a time they make sense, but sometimes they are hard to adapt to. Probably one of the most debated, and when it comes down to it unimportant, features of many coding standards is the way you format your code. Not that code formatting is unimportant, I think it is very important and, again, can go a long way to make your code look more professional. The part that really doesn't matter is how you do it. I don't care if you use 2,3,4 spaces, tabs, or some other variation that nobody has thought up yet. The point is to format the code. The idea is to make it easier to read the code, so do what you like, or do what is required by your clients/employers.
The last one I want to mention is to use single quotes whenever you can. There is less processing necessary for single quotes so you're always going to be better off using single quotes. There are times when heredoc, or other double quote type behavior is necessary but save it for when it's needed. I think I see double quotes overused most often by ASP/VBScript programmers that have learned PHP. They hear that PHP can use either so they just keep using double quotes as they were always used to without learning what the difference is and when to use which.
I'm sure there are more pointers that could be added on here and I just might continue adding them as they come up. The idea of these standards are to help separate the men from the boys so to speak. In the programming climate that PHP resides there are a lot of boys, whatever we can do to look more professional is definitely worth it.
No comments yet