nav-left cat-right
cat-right

Ten PHP Best Practices Tips that will get you a job

The last couple of weeks have been quite the experience for me. I was part of a big layoff at my former company, which was interesting. I've never been in that position before, and it's hard not to take it personally. I started watching the job boards, and a nice-looking full-time PHP position caught my eye, so I sent out a resume and landed an interview. Before the face-to-face portion, I chatted with the owner and head programmer on a conference call, and they ended up sending me a technical assessment quiz. One particular question caught my eye on this quiz… it looked something like this:

Find the errors in the following code:

<?
function baz($y $z) {
	$x = new Array();
	$x[sales]  = 60;
	$x[profit] = 20:

	foreach($x as $key = $value) {
		echo $key+" "+$value+"<BR>";
	}
} 

?>

So, give it a shot. How many can you find?

If you got the missing comma in the parameter list, the "new Array()" error, the colon instead of a semi-colon, the '=' instead of '=>' in the foreach statement, and the erroneous use of '+' on the echo line, then congratulations, you found all the errors! You have the basic PHP technical skills to pay the bills.

That's not how I answered the question though. I noted the errors, obviously, but I went further than that. For instance, did you notice that there were no single quotes around the array indexes ($x[sales] and $x[profit])? That won't cause a fatal PHP error, but it is a coding error! Did you also notice the use of double-quoted strings instead of single-quoted strings on the echo line? Or the usage of the opening PHP short tag? Or the usage of "<BR>" instead of "<br/>"?

After pointing out the actual errors, I made a point of adding comments about those things I just mentioned. It was enough to push the answer from "correct" to "impressive", and it scored me a lot of points with the programmers who were reviewing my application. Enough so that they offered me the job! (I eventually turned it down, as I have been seduced by the siren call of the contracting life, and I intend to flex my PHP skills to the benefit of my clients, and not a faceless corporate overlord who dabbles in telemarketing. I need a shower).

So, read on for my Ten PHP Best Practices Tips that will get you a job:

1. Single-quoted strings are your friend. When you surround a PHP string in double quotes, it is subsequently parsed by the PHP interpreter for variables and special characters, such as "\n". If you just want to output a basic string, use single quotes! There is a marginal performance benefit, since the string does not get parsed. If you have variables or special characters, then by all means use double-quotes, but pick single quotes when possible.

2. String output. Which line of code do you think runs faster?

print "Hi my name is $a. I am $b";
echo "Hi my name is $a. I am $b";
echo "Hi my name is ".$a.". I am ".$b;
echo "Hi my name is ",$a,". I am ",$b;

This might seem weird to you, but the last one is actually the fastest operation. print is slower than echo, putting variables inline in a string is slower than concatenating them, and concatenating strings is slower than using comma-separated echo values! Not only does not-inlining your variables give you a performance boost, but it also makes your code easier to read in any editor that has syntax highlighting (your variables will show up in nice colors). The little-known use of echo as a function that takes a comma-separated list of values is the fastest of them all, since no string operations are performed, it just outputs each parameter. If you combine all this with Tip #1 and use single quotes, you're on your way to some finely-tuned strings.

3. Use single-quotes around array indexes. As you saw in the quiz question above, I pointed out that $x[sales] is technically incorrect! You should quote associative array indexes, like so: $x['sales']. This is because PHP considers the unquoted index as a "bare" string, and considers it a defined constant. When it can't find a matching symbol for this constant in the symbol table however, it converts it to a real string, which is why your code will work. Quoting the index prevents this constant-checking stuff, and makes it safer in case someone defines a future constant with the same name. I've also heard that it is up to seven times faster than referencing an unquoted index, although I haven't tested this. For more on this, see the section called "Array do's and don'ts" in the Array section of the PHP manual.

4. Don't use short open tags. Eww… are you really using these? <? is just bad form. It can cause conflicts with XML parsers, and if you ever distribute code, it's going to annoy the heck out of people who have to start modifying their PHP ini directives to get it to work. There's just no good reasons to use short open tags. Use the full <?php.

5. Don't use regular expressions if you don't need to. If you're doing basic string operations, stay away from the preg and ereg function groups whenever possible. str_replace is much faster than preg_replace, and strtr is even faster than str_replace! Save those crunch cycles… your enterprise applications will thank you.

6. Don't use functions inside a loop declaration. This isn't a PHP-specific tip, but you'll see it in a lot of code.

Bad:

for ($i = 0; $i < count($array); $i++) {
//stuff
}

Good:

$count = count($array);
for($i = 0; $i < $count; $i++) {
//stuff
}

That should be pretty self-explanatory, but it's amazing how many people would rather save a line of code at the expense of performance. If you use a function like count() inside a loop declaration, it's going to get executed at every iteration! If your loop is large, you're using a lot of extra execution time.

7. Never rely on register_globals or magic quotes. register_globals and magic quotes are both old features of PHP that seemed like a good idea at the time (ten years ago), but in reality turned out to be not that great. Older installations of PHP would have these features on by default, and they cause security holes, programming errors, and all sorts of bad practices, such as relying on user input to create variables. Both these features are now deprecated, and everyone needs to stop using them. If you are ever working on code that relies on these features, get it out of there as soon as you can!

8. Always initialize your variables. PHP will automatically create a variable if it hasn't been initialized, but it's not good practice to rely on this feature. It makes for sloppy code, and in large functions or projects can become quite confusing if you have to track down where it's being created. In addition, incrementing an uninitialized variable is much slower than if it was initialized. It's just a good idea.

9. Document your code. You've heard it many times, but this can't be said enough. I know places that won't hire people who don't document code. I even got my previous job after an interview where the VP sat-in with the interviewer and I, where I had brought my laptop in and I was just scrolling through some code I had written for one of my sites. He saw my documented functions and was impressed enough to ask me about my documenting habits. A day later I had the job.

I know a lot of self-declared PHP gurus out there like to pretend that their code is so good that they don't have to spend time documenting it, and these people are full of $largeAnimal poop. Learn docblock syntax, familiarize yourself with some PHP Documentation packages like phpDocumentor or Doxygen, and take the extra time to do it. It's worth it.

10. Code to a standard. This is something that you should ask potential employers about during interviews. Ask them what kind of coding standards they use… PEAR? Zend? In-house? Mention that you code to a specific standard, whether it be your own, or one of the more prevalent ones out there. The problem with loosely-typed languages like PHP is that without a proper coding standard, code tends to start looking like huge piles of garbage. Stinky, disgusting garbage. A basic set of rules that includes whitespace standards, brace matching, naming conventions, etc. is a must-have, must-follow for anyone who prides themselves on their code quality.

That being said, I hate all you space-indenters. I mean, what the hell? 4 space characters as an indent? That's exactly four times as much whitespace to parse as a tab. More importantly, you can set your tab-stops to any value you want if you're using any text-editor more advanced than Notepad, so every developer can having something that they like the looks of. Set it to 4 if you want, or 0 if you're a masochist. I don't care, but you can't do that with spaces! You're stuck with exactly the amount that Mr. Monkey Pants in cubicle 17 decided to put in. So why are spaces so popular? This "4-space indent" standard everyone uses is stupid! Stop it! Stop doing it!

… sorry, pet peeve.

Anyway, I hope these tips are helpful. If you want to impress at a job interview, it's the little details that will get you noticed! Maybe don't rant about your coding standards though.

Be Sociable, Share!

167 Responses to “Ten PHP Best Practices Tips that will get you a job”

  1. wsworth.com says:

    Great Inf: good techniques….

  2. Jason says:

    I feel relieved, because I was able to find every single error in the code, except the short open tags, because I started reading the code at "function(…)"

    Good article, although I learned nothing new lol, it is good to keep my mind thinking with these practices.

  3. John_Betong says:

    Why not have default parameter values?

    Also passing parameters which are not used is confusing.

    Calling the function will trigger an error/warning of missing parameters.

  4. hackcorp says:

    I have some input on "So why are spaces so popular?". Tabs are treated differently in different text editors. While tab may look the same on the most windows editors, it looks way different in some linux ones and everything looks misaligned, where a space is a space and it is the same. I had problems with tabs when I had to change the code live on linux a few times, but I still mostly use spaces as these scenarios do not happen ofter. Tab is easier, I agree, but if you do a lot of linux/windows cross-server coding, spaces are a better solution imho. :)

  5. meMyselfAndI says:

    Great article… Was hoping to find some things that I didn't adhere too… But does feel good reading this, the fourth article on best practices, that am 98% in compliance. :) I code in Windows, so the Tab issue I completely agree with. That being said, I do upload to a *nix production server, and might try the 4 space idea. Would be nice to perhaps do a huge find of the TAB and replace with 4 spaces… One other note, after you specify the importance of single quoting your strings, your example of the echo concatenation is only using double quotes… No biggie, but thought it might appear better if you at least practice what you preached in your own article… :)

    Cheers!

  6. Hosting Best says:

    I got a few of the proper ones but I also got the single quotes error and the HTML next line should obv be

  7. briedis says:

    1. and 2. (except the print) point is hair splitting. One bad statement can bring down performance much much more than double quotes.
    Talking about convenience:
    echo "$a is $b and {$array['key']}!"; or
    echo $a . ' is . $b . ' and ' . $array['key'] . '!';

    4. or ? XML parsing is a poor excuse for not using this cool shorthand. Shorttags aren't deprecated, and a hostings that won't allow to turn them on is just a bad idea.

  8. Ramin says:

    Nice list. Thanks!

  9. raveren says:

    Protip: never optimize until you really really must, but you won't believe me now and will learn that yourself after some years, so just saying.

    Also, **all** of your micro-optimization assumptions are wrong:
    http://www.phpbench.com/

    Quotes don't matter, echo 'a'.'b' is faster.

  10. Very nice article! Thanks!!

  11. Craiger says:

    That's funny, I went and reviewed the PEAR standards site and they recommend using 4-space indents as the standard, without tabs. I use tabs, of course, because spaces make me mad when others do them as well, but it was jut funny.

  12. media vinz says:

    Cool stuff
    cheers
    zend practicing

  13. Jared says:

    Hey! I like my spaces. :-P I do not believe that echo and print have a performance difference in PHP5+….can somebody verify this? Thanks for the tips!

  14. vishal says:

    I spend my whole 4yr for php development and never used coding standard and php documenter. This is biggest mistake i made. Thanks for letting me know. this suggested stuff should be followed by all beginner. It make them understand what php development is all about.

  15. Bird says:

    good advice

  16. webmasta says:

    very good – however, pale grey text on a white bg wont get you the job at my company… all for your information and guidance.

  17. Paul says:

    You only got about half the total points that could be made with that code. This matches your success rate for the half black you got for the text on this page.

    Other things would have been:

    a lack of comments

    unused y and z which should be named sales and and profit so that the hard coded values can be removed

    The array should be initialised in one step: array('sales' => $sales, 'profit' => $profit)

    Also, why no OO?

    I think I would be too hard on their poor piece of code, so maybe they would want you rather than me anyway.

  18. very nice article. I am using some coding standards and I think the list above will surely help me to improve more.

    Thanks
    Dhanesh Mane

  19. tarun says:

    nice..good basic points every one should remember..

  20. Habeeb Perwad says:

    Good One…

  21. Sanjeeb Sahu says:

    Nice article..After reading i got some basic idea over php. Thanks a lot…

  22. I find that in most companies there is a syntax tzar who dictates the "right and wrong" way of formatting code. The safest thing to do career-wise is to keep up to date with developers who work collaboratively. That is how you can avoid going way out into the left field.

  23. [...] Helpful Links: Ten PHP Best Practices Tips that will get you a job [...]

  24. Thangaraj says:

    Good job!!!

  25. [...] Posted by blake on Jun 4, 2008 in Code , Performance , PHP | 154 comments The last couple of weeks have been quite the experience for me. I was part of a big layoff at my former company, which was interesting. I've never been in that position before, and it's hard not to take it personally. I started watching the job boards, and a nice-looking full-time PHP position caught my eye, so I sent out a resume and landed an interview. Ten PHP Best Practices Tips that will get you a job | PHP vs .Net [...]

  26. Areshandore says:

    Mine answer would be something like this:

    $value)
    {
    $tmp_buffer.= "$key : $value ";
    }
    echo $tmp_buffer;
    }

    //do not close php tag if the script finishes here
    ?>

  27. Areshandore says:

    <?php
    // Note: Would be better to give this function a more meaningfull signature
    function baz($y,$z)
    {
    $x=array();

    $x["sales"]=60;
    $x["profit"]=20:
    $tmp_buffer="";
    foreach($x as $key=>$value)
    {
    $tmp_buffer.= "$key : $value <br />";
    }
    echo $tmp_buffer;
    }
    //do not close php tag if the script finishes here
    ?>

  28. Chris says:

    Excellent article :)

  29. Blake,

    I would like to publish a spanish translation of your article within my blog keeping a link to your original article as source of translation. Let me know.

    Regards

  30. RMC says:

    These tips should be revised! Check out phpbench for details on speed issues, for instance, as these tend to change from version to version (the doubly quoted string performance issue virtually doesn't exist in PHP5, and it tends to depend on the actual usage of an embedded variable).

    As for the vs. :
    You did not specify XHTML, so cannot incorrect. Furthermore, with HTML5, non-selfcclosing tags are back in the game. is only accepted for compatibility with XML-style HTML.

    Also: a function call in a foreach declaration is fine (foreach $model->getDataAsArray() as $entry) is fine). It would be good to see these kinds of context to each of your tips.

    @Paul: why no OO? Because using OO is overkill in a small piece of code such as this! Or do you thing that the object-creation overhead is OK while double-quotes are evil?

    @briedis: Short opening tags is a good idea?! And I suppose you want to allow ASP-style tags too? Why not interpret everything that is not inside tags as PHP?!
    If you can use code to be clear about what's what, you don't need to add a comment explaining what kind of script it is. Compare:
    <?php
    with
    <? // PHP

  31. RMC says:

    Oops, correction for missing HTML tags (using square brackets):

    As for the [BR] vs. [br /]:
    You did not specify XHTML, so [BR] cannot incorrect. Furthermore, with HTML5, non-selfcclosing tags are back in the game. [br /] is only accepted for compatibility with XML-style HTML.

  32. Santhosh says:

    Nice tips for php developers.
    Keep Continuing…

  33. N13 says:

    it was a gr8 help…:)

  34. Janet says:

    Nice article. I'd also recommend reading http://www.jobstock.com/blog/php-jobs-top-tips-for-finding-your-dream-php-job/ . Very help for those looking for PHP jobs.

  35. bharath says:

    gud one

  36. [...] Ten PHP Best Practices Tips that will get you a job [...]

  37. Excellent beat ! I wish to apprentice whilst you amend your web site, how can i subscribe for a blog web site?
    The account aided me a acceptable deal. I had been tiny bit acquainted of this your
    broadcast provided shiny transparent concept

Leave a Reply