This is the first article that I’m writing about learning PHP.
For a couple of months now, and even more after this article from Marco Tabini, I have noticed the need of better coding standards and a more directed learning content for “greenhorn” programmers in PHP.
Based on this, I’m starting today with a PHP Basis Series that will try to get around all the basic need that a developer should have to program well in PHP.
This first article will cover everything you need to know about coding and it’s standards.
It’s important that you have good standards and coding techniques and to emphasize that I quote a professor of mine that once said: ” A good developer learn the best pratices, standards and coding techinques, so he can program in any language.”.
While talking in PHP we have a small list of good coding practices / standars and methods.
When declaring variables and functions, use camelCase.
It’s actually simple. The variable or function will have it’s name started with a lower case and the next word will have the first letter uppercase and this will repeat for every word after.
Constants are always UPPERCASE.
This rule is more to help you out on identifying the constants among the variables.
Variables, functions names and constants must have a meaningful name.
Consider the following function:
function funtion_1($var, $var2)
for($i = 0; $i < $var2; $i++)
$var = $i + $var2;
Looking it like this, it’s very, very hard to understand what is the use for the function or what each variable means, but re-writing it like this:
function increaseByMany($numberSource, $counter)
for($index = 0; $index < $counter; $index++)
$numberSource = $index + $counter;
It get’s really easier to understand whtat is doing and what it will return.
Use 4 spaces instead of Tabs.
Consider that you are working remotely with other developers from all over US and the World. Each developer has it’s own preferable editor. The only problem with this is that each editor can be configured to set the number of spaces for the tabs, so a developer can have 8 spaces instead of 4, for each tab. With the objective to have the correct indentation on every editor, instead of using tabs, use 4 spaces. It will be annoying at first, but it does really pay in the long run.
Have the minimal documentation for the system even if it is on the function / class itself.
This example is better visualized on a object class. Consider the creation of a class that handles every single action that a user can do on the system and this class was created more than 6 months ago. If you don’t have any inline documentation, or any documentation at all, understanding the methods inside and some specific methods from the class can be very hard. To avoid that and to allow other developers to understand how the class works, you should at least do inline commeting.
Some systems like PHPDoc, can grab the inline comments that you have written on your class and convert it, automatically, to a very professional system documentation.
Consider working with Object Oriented Programming, scalability and modularity.
Even if you are starting, working with Object Oriented Programming is a need and doing it so in a modular and scalable way is a must. The reason to work with OOP is simple: code re-use and modularity. If is well developed, you can easily allow a developer to work on a part of the system while you work on another, or you can let a developer to use a object that you already have created on his part of the system. The most important thing is that the system get’s easier to read, easier to maintain and you win on development time since you wont need to re-invent the wheel. The scalability is something that every system should consider on it’s beginning. If your system is not scalable enought there is a good chance that at some point, it will fail because it can’t grow.
Do your analysis before witting anything.
In one of my first jobs I have worked as a system architech and it was insane hard to convice the CEO that before acting, we need a plan, or by that I mean, we need to do analysis. Every time that my team tried to create something without discussing it first, things did go wrong, so, from a personal experience, if you are the system architech, do your analysis on the issue first. It will save time and you will be albe to consider how modular and scalable it can be.
Specifically to PHP
1. Never use short tags and it’s variations
2. If the document only contains PHP code, no need to use the PHP close tag ( ?> )
These are the very few basics from coding pratices / standards. Before writting a code always consider that it can become huge, that it can have 10 milhon users at time and, most important, that another developer will be reading it.
This will help you to write better code and as an advise, get the best coding standards that are out there, make a list and set on a document so every system that you work from now on you can use those and, off course, if someone joins the boat, you can send him that document too.