Menu Search
Jump to the content X X
Smashing Conf New York

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. upcoming SmashingConf New York, dedicated to smart front-end techniques and design patterns.

10 Advanced PHP Tips To Improve Your Programming

Advertisement

Update (25.03.2009): this article contains some factual errors. Please read the rebuttal of this article1 instead of this article.

PHP programming has climbed rapidly since its humble beginnings2 in 1995. Since then, PHP has become the most popular programming language for Web applications. Many popular websites are powered by PHP, and an overwhelming majority of scripts and Web projects are built with the popular language.

Because of PHP’s huge popularity, it has become almost impossible for Web developers not to have at least a working knowledge of PHP. This tutorial is aimed at people who are just past the beginning stages of learning PHP and are ready to roll up their sleeves and get their hands dirty with the language. Listed below are 10 excellent techniques that PHP developers should learn and use every time they program. These tips will speed up proficiency and make the code much more responsive, cleaner and more optimized for performance.

1. Use an SQL Injection Cheat Sheet Link

Sql Injection3
A list of common SQL injections.

SQL injection4 is a nasty thing. An SQL injection is a security exploit that allows a hacker to dive into your database using a vulnerability in your code. While this article isn’t about MySQL, many PHP programs use MySQL databases with PHP, so knowing what to avoid is handy if you want to write secure code.

Furruh Mavituna has a very nifty SQL injection cheat sheet5 that has a section on vulnerabilities with PHP and MySQL. If you can avoid the practices the cheat sheet identifies, your code will be much less prone to scripting attacks.

2. Know the Difference Between Comparison Operators Link

Equality Operators6
PHP’s list of comparison operators.

Comparison operators7 are a huge part of PHP, and some programmers may not be as well-versed in their differences as they ought. In fact, an article at I/O reader states that many PHP developers can’t tell the differences right away between comparison operators. Tsk tsk.

These are extremely useful and most PHPers can’t tell the difference between == and ===. Essentially, == looks for equality, and by that PHP will generally try to coerce data into similar formats, eg: 1 == ‘1′ (true), whereas === looks for identity: 1 === ‘1′ (false). The usefulness of these operators should be immediately recognized for common functions such as strpos(). Since zero in PHP is analogous to FALSE it means that without this operator there would be no way to tell from the result of strpos() if something is at the beginning of a string or if strpos() failed to find anything. Obviously this has many applications elsewhere where returning zero is not equivalent to FALSE.

Just to be clear, == looks for equality, and === looks for identity. You can see a list of the comparison operators8 on the PHP.net website.

3. Shortcut the else Link

It should be noted that tips 3 and 4 both might make the code slightly less readable. The emphasis for these tips is on speed and performance. If you’d rather not sacrifice readability, then you might want to skip them.

Anything that can be done to make the code simpler and smaller is usually a good practice. One such tip is to take the middleman out of else statements9, so to speak. Christian Montoya has an excellent example10 of conserving characters with shorter else statements.

Usual else statement:

if( this condition )
{
$x = 5;
}
else
{
$x = 10;
}

If the $x is going to be 10 by default, just start with 10. No need to bother typing the else at all.

$x = 10;
if( this condition )
{
$x = 5;
}

While it may not seem like a huge difference in the space saved in the code, if there are a lot of else statements in your programming, it will definitely add up.

4. Drop those Brackets Link

Drop Brackets11
Dropping brackets saves space and time in your code.

Much like using shortcuts when writing else functions, you can also save some characters in the code by dropping the brackets in a single expression following a control structure. Evolt.org has a handy example12 showcasing a bracket-less structure.

if ($gollum == 'halfling') {
$height --;
}

This is the same as:

if ($gollum == 'halfling') $height --;

You can even use multiple instances:

if ($gollum == 'halfling') $height --;
else $height ++; 
 
if ($frodo != 'dead')
echo 'Gosh darnit, roll again Sauron';
 
foreach ($kill as $count)
echo 'Legolas strikes again, that makes' . $count . 'for me!';

5. Favour str_replace() over ereg_replace() and preg_replace() Link

Str Replace
Speed tests show that str_replace() is 61% faster.

In terms of efficiency, str_replace()13 is much more efficient than regular expressions at replacing strings. In fact, according to Making the Web, str_replace() is 61% more efficient than regular expressions like ereg_replace()14 and preg_replace()15.

If you’re using regular expressions, then ereg_replace() and preg_replace() will be much faster than str_replace().

6. Use Ternary Operators Link

Instead of using an if/else statement altogether, consider using a ternary operator16. PHP Value gives an excellent example of what a ternary operator looks like.

//PHP COde Example usage for: Ternary Operator
$todo = (empty($_POST[’todo’])) ? ‘default’ : $_POST[’todo’]; 
 
// The above is identical to this if/else statement
if (empty($_POST[’todo’])) {
$action = ‘default’;
} else {
$action = $_POST[’todo’];
}
?>

The ternary operator frees up line space and makes your code less cluttered, making it easier to scan. Take care not to use more than one ternary operator in a single statement, as PHP doesn’t always know what to do in those situations.

7. Memcached Link

Memcached17
Memcached is an excellent database caching system to use with PHP.

While there are tons of caching options out there, Memcached18 keeps topping the list as the most efficient for database caching. It’s not the easiest caching system to implement, but if you’re going to build a website in PHP that uses a database, Memcached can certainly speed it up. The caching structure for Memcached was first built for the PHP-based blogging website LiveJournal.

PHP.net has an excellent tutorial on installing and using memcached19 with your PHP projects.

8. Use a Framework Link

Framework20

CakePHP is one of the top PHP frameworks.

You may not be able to use a PHP framework for every project you create, but frameworks like CakePHP21, Zend22, Symfony23 and CodeIgniter24 can greatly decrease the time spent developing a website. A Web framework is software that bundles with commonly needed functionality that can help speed up development. Frameworks help eliminate some of the overhead in developing Web applications and Web services.

If you can use a framework to take care of the repetitive tasks in programming a website, you’ll develop at a much faster rate. The less you have to code, the less you’ll have to debug and test.

9. Use the Suppression Operator Correctly Link

The error suppression operator (or, in the PHP manual, the “error control operator25“) is the @ symbol. When placed in front of an expression in PHP, it simply tells any errors that were generated from that expression to now show up. This variable is quite handy if you’re not sure of a value and don’t want the script to throw out errors when run.

However, programmers often use the error suppression operator incorrectly. The @ operator is rather slow and can be costly if you need to write code with performance in mind.

Michel Fortin has some excellent examples26 on how to sidestep the @ operator with alternative methods. Here’s an example of how he used isset to replace the error suppression operator:

if (isset($albus))  $albert = $albus;
else                $albert = NULL;

is equivalent to:

$albert = @$albus;

But while this second form is good syntax, it runs about two times slower. A better solution is to assign the variable by reference, which will not trigger any notice, like this:

$albert =& $albus;

It’s important to note that these changes can have some accidental side effects and should be used only in performance-critical areas and places that aren’t going to be affected.

10. Use isset instead of strlen Link

Strlen
Switching isset for strlen makes calls about five times faster.

If you’re going to be checking the length of a string, use isset instead of strlen. By using isset, your calls will be about five times quicker. It should also be noted that by using isset, your call will still be valid if the variable doesn’t exist. The D-talk has an example of how to swap out isset for strlen:

A while ago I had a discussion about the optimal way to determine a string length in PHP. The obvious way is to use strlen().

However to check the length of a minimal requirement it’s actually not that optimal to use strlen. The following is actually much faster (roughly 5 times)

It’s a small change but, like all the tips we’ve covered today, adds up to quicker, leaner code.

(al)

Footnotes Link

  1. 1 https://www.smashingmagazine.com/2009/03/24/10-useful-php-tips-revisited/
  2. 2 http://en.wikipedia.org/wiki/PHP
  3. 3 http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#AboutMySQLandPHP
  4. 4 http://en.wikipedia.org/wiki/SQL_injection
  5. 5 http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#AboutMySQLandPHP
  6. 6 http://docs.php.net/manual/en/language.operators.comparison.php
  7. 7 http://docs.php.net/manual/en/language.operators.comparison.php
  8. 8 http://docs.php.net/manual/en/language.operators.comparison.php
  9. 9 http://us3.php.net/else
  10. 10 http://www.christianmontoya.com/2007/11/09/php-techniques-i-use-all-the-time/
  11. 11 http://evolt.org/these-things-i-know-php-tips
  12. 12 http://evolt.org/these-things-i-know-php-tips
  13. 13 http://us.php.net/manual/en/function.str-replace.php
  14. 14 http://us.php.net/manual/en/function.ereg-replace.php
  15. 15 http://us.php.net/manual/en/function.preg-replace.php
  16. 16 http://www.phpvalue.com/what-is-php-ternary-opeartor/
  17. 17 http://www.danga.com/memcached/
  18. 18 http://www.danga.com/memcached/
  19. 19 http://us3.php.net/memcache
  20. 20 http://www.cakephp.org
  21. 21 http://www.cakephp.org
  22. 22 http://framework.zend.com/
  23. 23 http://www.symfony-project.org/
  24. 24 http://codeigniter.com/
  25. 25 http://us2.php.net/operators.errorcontrol
  26. 26 http://michelf.com/weblog/2005/bad-uses-of-the-at-operator/
SmashingConf New York

Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf New York, on June 14–15, with smart design patterns and front-end techniques.

↑ Back to top Tweet itShare on Facebook

Glen Stansberry is the editor at Web Jackalope, a blog about creative Web development.

Advertisement
  1. 1

    great!!

    -5
  2. 2

    Amazing…….

    -5
  3. 3

    nice article

    -14
  4. 4

    these are great although not using common brackets and universal indentation will just make it harder to read code

    14
  5. 5

    Dropping the brackets is a great way to make your code less readable. It’s a stupid tip.

    59
  6. 6

    I don’t really agree with dropping brackets left and right. I’ve always been taught it’s good practice to use them, because you can easily see where the conditions/loops are when scanning your code. Same with the use ternary operators and other shorthands – people overuse them and it makes it nearly impossible to debug their code later down the road.

    Let me ask, has anybody really noticed a difference in speed/load with:
    $var = "my name is bob";
    compared to
    $var = 'my name is bob';
    I’ve never noticed a difference in speed myself, even with pretty high loads.

    10
  7. 7

    I see some bad ideas here. Applying the techniques #4, #6 and #9 will result in lesser readable and maintainable code. A little sidenote concerning performance: It is better to write good code and use caching techniques to increase performance.

    7
  8. 8

    Oh yeah, this article came just in time!! I needed the SQL Injection Cheat Sheet today!

    1
  9. 9

    Some of these tips are micro-optimizations while others are universally useful. I want to add a couple things to the mix:

    – Upgrade your PHP installation to the latest version… currently it’s 5.2+. This way, you can be certain that your server has the latest bugfixes.
    – Use an opcode cacher, like APC, to speed up your execution time. Opcode cachers saved compiled versions of your scripts, so they don’t have to be compiled every time they are run. This will make any PHP site much faster.
    – Use the mysqli class that comes with PHP 5 instead of the old mysql. This allows you to do object-based queries with bound parameters, which prevents SQL injection by ensuring that every parameter will be checked and forced to be an integer or a string, and will then be contained within the query, even if they have quotation marks injected.

    But the most important tip I can share is, always be learning!

    5
  10. 10

    I don’t see a speed difference when choosing or . I would recommand using . Because in notepad++, the $var is good colored !

    Nice post.

    -1
  11. 11

    Tips 3 and 4 are really bad. It’s much better to use certain coding styles.

    6
  12. 12

    This is just blatant irresponsible use of the word “advanced”

    How the heck is knowing the difference between == and ===, advanced?
    or that str_replace is faster than regex?

    You learn this crap in your first pass through the manual.

    I eagerly clicked to read this article because i thought to myself, ‘ok, something new has been found out’ and all i found was this marketed garbage.

    shame on you.

    11
  13. 13

    I like this article, it points out a regular problem : performances vs legibility.

    Personally, I always drop the brackets when I can (meaning : a short test and a single short consequent). I know this is considered to be less readable, but if it is the case, it’s probably that this is the consequent (or the test) that isn’t readable enough, not the conditional form itself (providing you use a good indentation).

    On the other hand, #10 seems to be definitively tricky when you read it.

    @matt : I agree with you, but here, it is to use caching techniques *and* to write fast code. The audience must be extreme speed requirement applications.

    -2
  14. 14

    You PHP people are funny

    1. If you don’t know the difference between comparison operators you shouldn’t be coding.

    2. Use brackets, please use them, they make the code easier to read and it’s good practice.

    3. If your code is open to SQL Injection then you don’t know how to code. I could understand people having this problem ten years ago.

    4. Shortcut else? Just lazy mans code.

    Tip of the day! Use ASP.NET/C#.NET

    C# is an ISO standard, I don’t think PHP is?

    -33
  15. 15

    Giovanni Battista Lenoci

    November 18, 2008 6:47 am

    I don’t agree with tip 4, dropping brackets make code less readable.
    I use sometimes ternary operators, but also this tecnique make code less readable.
    I’ve never tested a code with brackets an without brackets, but I don’t think that the results are so different.

    Reguarding tip #9, I don’t know what was in the writer mind, but without an explanation this could lead to unwanted results:

    $a = 5;
    $b = $a;
    $a = 10;
    echo $a."-".$b; // 10 - 5
    $a = 5;
    $b =& $a;
    $a = 10;
    echo $a."-".$b; // 10 - 10

    For other tips, some are ok, some are banal.
    I suggest to change the article title in to 10 Advanced PHP Tips To Improve Your Programming (not so much)

    1
  16. 16

    troll ?

    3
  17. 17

    Great but you should rename the post to:

    “6 adavanced tips to mess up your code!”

    0
  18. 18

    Tip 4 is just bad advice, it goes against most “best practices”. What if you add one more line in the future? You’ll forget the brackets and your code doesn’t work as it should!

    Tip 9 is just as bad. It even goes against Zend recommendations. In the Zend recommendations it is explicitly stated that you should never assign by reference unless you really need it. Also the other side-effects this might cause is another reason to not use assign-by-reference just to avoid a suppression operator.

    Tip 6 is debatable. Some guidelines ask to not use ternary operators to improve readability. If I’m not mistaken that is one of the reasons it’s not in Python.

    The author of this article is one PHP Coder I’d rather not hire and it’s really a shame that this article has appeared on SmashingMagazine.

    0
  19. 19

    Agree with the previous posters, there are some dreadful tips here. Shorthand else and dropping braces do nothing but decrease the legibility of your code.

    Shorter code in terms of short cuts like these are not a sign of good code. “Anything that can be done to make the code simpler and smaller is usually a good practice” is a terrible generalisation. Far better practices to adhere to are following OO programming principles that encourage reusable, modular code.

    Furthermore, the article is contradictory – it encourages you to use a framework, but those frameworks have coding standards that automatically invalidate these two rules! For example, the Zend framework states: “PHP allows statements to be written without braces in some circumstances. This coding standard makes no differentiation- all “if”, “elseif” or “else” statements must use braces.”

    This article is a good idea, but has been poorly thought out.

    2
  20. 20

    I don’t agree with the 4th tip.

    5
  21. 21

    “Drop those Brackets” is a bad tip…

    3
  22. 22

    I’m with everyone else, even before I read the comments.

    That’s a list of things to do if you’re a lazy developer, for the most part.

    I like the logic behind Apple’s Objective-C standards. Write more, not less. Be more descriptive.

    We spend more time reading code than writing it for the most part, lean towards readability.

    #6 is iffy. Ternary operators have their place, but I’ve often seen them overused.

    #8 is even tricky. You shouldn’t use a framework unless you really understand the language. I use Zend, including the whole MVC pattern it supports, but for a new developer to use it is a bad idea. No framework is perfect. As much testing as gets done, there are always bugs. I’ve had to fix issued in Zend before, and more in Cake… not terrible, but for a new developer they are going to be lost and never understand what the problem is…

    Poor article, well below the standards of this site.

    3
  23. 23

    Actually thee difference between single-quote ‘ and double-quotes ” can add up over an entire application. For example, the command:
    $var = 'Test';
    $st = "This is a string called $var";

    vs.
    $st = 'This is a string called ' . $var;
    in the first line, the string will be parsed for variables and then they will be evaluated. In the second line the two strings are concatenated. The second can offer some speed advantages. Even if the first string did not contain a variable it would still be evaluated for variables.

    In cases where you use a string as an index (in an array for instance) you would find that
    $my_array['keyvalue'] would be more efficient than $my_array["keyvalue"]or (heaven forbid) $my_array[keyvalue].

    If you do a lot of string wrangling (in localization for instance) you will notice a difference in speed.

    3
  24. 24

    #4 contradicts how he wrote #6 as he’s using brackets in the if() statement.

    I used to write code using no brackets for one-lined statements, but I look back now and think “WTF?”. It’s formatted nicely in #9, but in all fairness, you would probably miss that you are doing an if() statement there if you are just breezing through code; least when I breeze through now, I see where I did loops/if()s and such like as these are the most comment error places I find in my code.

    C David Dent: I also find using ‘This is ‘.$value makes it easier to spot where the variables are in a string and forcing you out of causing possible errors.

    5
  25. 25

    Moritz Stefaner

    November 18, 2008 7:17 am

    Sorry, but 3 and 4 are definitely bad advice. 6 has some nice applications, where it really looks better, but I wouldn’t overuse it either, especially with lengthy conditions and value assignments.

    2
  26. 26

    yupii symfony ;)

    2
  27. 27

    You should apply #6 to #3:

    $x = (this condition) ? 5 : 10;

    It only makes one assignment (unlike the “shortcut” version), and requires even less code. I realize people have mixed views on the ternary operator, but it’s honestly only confusing to people who refuse to use them.

    2
  28. 28

    i have to echo those concerns about 3 and 4 … particularly #4 with respect to code readability and future maintainability. i work with a relatively large php code base that was written back in the heyday of php 4 and among all of the fun procedural practices that i am cleaning up at the moment to convert to OO, i am very happy that the practice of leaving out braces was not used.

    good stuff otherwise! i can’t stress enough the importance of #7 … we have seen no less than a 400% increase in efficiency by utilizing memcached. the use of a framework is recommended as well. i personally recommend Zend Framework for anything other than a small rapid prototype (it has a flexible use at will architecture).

    1
  29. 29

    Thanks. PHP tips are always welcome!

    2
  30. 30

    Dropping the curly brackets, is very stupid, it makes the source less readable, and very easy to make mistakes, if you’re going to add a code line to that part of the sourcecode.
    So my tip would be, Use curly-brackets all over..

    0
  31. 31

    About using framework, beginner PHP developer could save time doing fast deadline project, but some of my friend are experienced in PHP, doesn’t like using framework, because they already have their own framework
    and better using bracket to make code more readeable, see coding standard from CakePHP

    1
  32. 32

    Drop the brackets: All I can say to this one is, NO! As a young programmer I’d omit the brackets all the time if it was only 1 line. But then what happens if you discover later on you need to do more stuff based on your enclosing condition? Now you have to add the brackets back in. As code gets more nested the readability tends to go down and if you fail to enclose your 1 line statements in brackets the situation only gets worse. A much much better tip would be, “Always use brackets, even if they only enclose 1 line of code”.

    The else statement tip has issues too. The if – then – else form has the advantage that the variable only gets set once. In the no else case, the variable can be set twice if the if condition is met. If you have an expensive function where the variable set is instead then the no else approach can get very costly. It also reduces readability as the logic tree the programmer is implementing can be obfuscated. If you see an if … else in a piece of code it’s obvious that there’s a “fork in the road” at that point where one of two blocks of code will be executed. This isn’t so obvious in the no else case. The size of the PHP script has no bearing whatsoever on the size of the output and the longer versions are more readable, and the poor bastard who has to come along and maintain your code in a few months time might just be yourself. It’s amazing how much you can forget about your own code if it’s not crystal clear what it’s doing.

    As for the final tip, this one carries an important caveat. You’re using a function for a job other than the one it was intended for, so be sure to leave a comment in your code explaining this. And while it might be five times faster, the time difference is probably not going to be noticeable unless you’re processing massive amounts of data in a loop. Beware premature optimization.

    The biggest performance hit you’re going to take in most PHP applications is almost certainly going to be the cost of talking to your database. My advice here is to treat talking to the database as if you’re looting for supplies in a zombie move – Get in, grab only what you need and get the hell out. The more queries you perform the slower your application will be, the more data the database returns in response to a query the slower your application will be, and the general rule is you’ll be doing far more SELECTs than you will be doing UPDATEs, INSERTs or DELETEs. If data doesn’t change often then cache it and avoid the database query altogether.

    2
  33. 33

    Glen Stansberry

    November 18, 2008 8:17 am

    Hi Everyone,

    It looks like there was a bit of a fever about tips #3 and #4. While I might not have stated it in the article, their is a difference in the readability of the code vs. the speed of the code. If you’re concerned about readability of your code, then by all means skip #3 and #4. I was just trying to point out some tips that might fall under the radar of a typical article.

    Thanks for your comments and suggestions!

    1
  34. 34

    i get more tips reading the comment rather than reading the post.. and a big NO to “Drop the bracket”..

    1
  35. 35

    Whoa, no response from SM, yet? Amazing :|

    0
  36. 36

    Using a well known framework can really help. You can invite other coders to ‘hope in’ your project and start developing with ease. As for the other tips all of them are sometimes bad/sometimes good.

    2
  37. 37

    Wow. Shortcut the else? lol Okay, that’s definitely not good advice. That’s an example of being too clever for your own good.

    1
  38. 38

    This is really a bunch of pretty wildly mixed tips.
    Tips like memcached or using a framework are certainly only useful for more experienced developers.
    Those however, would never drop common coding guidelines and readability to weird code that’s faster written or shorter as in lines.

    Ternaries are sometimes useful, however when having a quick glance at your own code, you’ll never really interprete them as fast or correct as a proper if/else statement. Same goes for the tip of avoiding the else at all.
    And never ever nest ternary operator statements.

    For unexperienced programmers writing smaller applications, it’s definitely overthrown to use a framework or to consider using memcached aswell.

    I’d say those tips should be regarded critically and i’d love to see a followup correcting that.

    0
  39. 39

    this hurts my head. Don’t drop the braces.

    single quotes are not faster than double quotes. If you say they are… then show the proof. I’ve run test after test of several servers and even at 10,000+ iterations the differences are negligible. Maybe in PHP 3 running on a Pentium 1 with 128MB RAM they were faster.. but come on people.. quit reading 3 year old blog posts and parroting them as truth.

    Also, it’s interesting how one tip such as “dropping braces” is included for speed, but the example of using Cake PHP framework is given when IMHO it’s an everused bloated piece of junk. Frameworks have their place and I’m not saying they aren;t good.. I just fail to see the consistency among the tips.

    One good one was the memcache tip. That is something that can help developers speed things up when they are trying to build an ap. but it doesn’t really help your programming.

    2
  40. 40

    Some excellent tips, some dumb ones. And some completely contradictory ones too.

    Like use a framework (an excellent tip), particularly CakePHP (one of the best). The CakePHP coding standard specifically advises against using ternary operators and not using brackets around code blocks in control structures.

    Making your code more efficient is a laudable aim. Making it harder to read and maintain is certainly not.

    0

↑ Back to top