Dave Dash

PHP double versus single quotes

2007-03-03T00:00:00-08:00

[tags]best practices, php[/tags]

If you're familiar with PHP, the difference between double and single quotes is obvious. Double quotes evaluate variables and control characters (e.g. \n or \r), whereas single quotes do not.

I've been indoctrinated with the "use single quotes whenever possible" methodology, but I never really put it to the test. Is it really worth it for me to go back and look at old code that uses double quotes and change them? Like all best practices, the answer is "maybe."

So I wrote a simple test harness (there's a lot of room for error with these, but I tried my best).

I tried different permutations of which order to run f1(), f2() and f3() they seemed to give similar results no matter which order they were run.

My results were:

Time 1: 2.898087978363
Time 2: 3.5480048656464
Time 3: 2.8503499031067

My interpretation is that quotes versus double quotes isn't as big of a deal as concatenation versus putting variables within double quotes. My guess is that PHP 5.2.0 (which is what I used for the tests) is smarter with strings than older versions.

So really if you look at the test harness there isn't any discernible differences until you hit 2 million iterations and even then nobody gets fired over 0.6 seconds of performance. Chances are it doesn't matter too much, but over time you can write enough code in the right spots or shared in the right open source projects and that few seconds will snowball. After all, I'm not so much concerned about how optimized a script is that I write, but rather how optimized is a script that everyone ends up using. But rather than do mental calculations about whether or not to optimize something, let's just assume that everything should be as optimal as we can stand to write it.

Update: 6 March 2006, I updated the test harness to reflect my intended tests. Update: 7 March 2006, I updated the results to be more clear.

Parsing a list of Key:Value pairs

2007-02-24T00:00:00-08:00

[tags]best practices,php,openID[/tags] I'm working on implementing openID for reviewsby.us and for use in symfony apps. One thing I was having trouble with was parsing key value pairs, which is one of the requirements to reading responses. It's a fairly easy task, but PHP offers so many ways to do this.

openID calls for the following Key-Value format:

Lines of:

some_key:some value

There MUST NOT be a space before or after the colon.

Newline characters MUST be Unix-style, just ASCII character 10 ("\n").

Newlines MUST BE at end of each line as well as between lines.

MIME type is unspecified, but text/plain is RECOMMENDED.

Character encoding MUST BE UTF-8.

So here is my attempt at parsing something like this as efficiently and error free as possible:

I wrote this function as I was writing the post... and it came out way faster than my previous implementations using strtok or a combination of explode and trim. Which is good to hear since I do use preg_ functions quite a bit in PHP and they definitely have their place.

I'm curious if people have found a faster way of parsing through a string of Key-Value pairs. I'll run it in a test harness and stand corrected if someone comes through with something faster ;).

Making anchor links smarter... and sexier

2007-02-14T00:00:00-08:00

So I have a small bone to pick with Jacob Nielsen and his opinion on within-page links or anchor links^.1 There clearly is a benefit to not just linking to a specific page, but linking to a specific part of a page.

With a little help from script.aculo.us we can spice up our anchor links by highlighting them as well as linking to them.

For this article we'll limit our scope to internal anchors only.² We'll write the code using the symfony framework and in straight up XHTML. This is really dirt simple and is more of a design pattern with an example than a tutorial.

Let's do the XHTML first:

Yup, that's it... I told you it was dirt simple. You just need to include the proper prototype and script.aculo.us libraries.

In symfony we avoid repeating ourselves with a helper function:

and call it by doing:

That's it.

Jacob Nielsen is an easy target. ↩
Anchors on other pages are equally useful. To implement that, you need to have an event listener to examine the URL for an anchor and appropriately highlight the correct element. ↩

Not taking frameworks for granted

2006-11-21T00:00:00-08:00

One of my clients approached me with a relatively easy project. She gave me a log file of PHP errors and I was supposed to fix her scripts. I fixed about 100+ different errors in a few hours. It was fairly straightforward.

Throughout the site I could understand the previous developer and the choices he or she made for better or worse. It did look like a struggle however.

Ultimately it felt that there were some fairly simple things that each script needed to do, but each task was a challenge. Validating forms, storing data across pages, decorating the site, interacting with the database. Everything seemed very kludged together.

I realized that this is exactly how I used to write code, sure... my way of course was better and more logical, yada, yada, yada... but ultimately I was there before.

My client noted that these scripts were made from another contract programmer, and then a light-bulb went on... frameworks (whether it be symfony, ROR, Django, CakePHP, etc) help iron out and standardize these tasks.

Since I know symfony best, I'll cover what I think could have helped in this last project. I'm sure other major frameworks have their equivalents.

Form validation: symfony lets you define form validation in a very simple manner. The validation logic is also separate from the rest of the code.
Storing Data: Without a framework, you generally have to rely on the $_SESSION array in PHP. While very useful and easy to use, storing parameters and attributes to a user object is done a lot more cleanly.
decorating the site: My biggest problem was with each page I had,, I used to have to call headers, sidebars, etc, etc. symfony's layout system was a boon. I had a common layout for all pages (maybe a few alternates) and hooks inside them if they needed to be adjusted. Then the various actions had their own seperate templates that were injected into the common layout. It made adding new pages easy, since I didn't need to remember header() and footer() functions for each and every page.
Interacting with the database: I've covered before the benefits of ORM.

Not only do the bulk of these problems disappear with a framework, a lot of the difficulties of switching developers melt away. If you tell me, a developer, that I'm walking into a project made with a framework, I can learn about the framework and be able to understand its ins and outs.

If you just tell me it's written in PHP, chances are I'm going to want to do things my own way. It's hard to understand the logic that another programmer was using so we fall back to standards whether they are your own or borrowed.

When we use a framework, we can find some mutually agreed upon standards and usually people who specialize in that framework and are willing to help. So my advice: stick to frameworks. The coding style will be no worse than the whims of a programmer, but at best it'll be something that anyone can pick up. The general case is that even a bad coder can only do so much damage within a framework. The bullet points I covered above will cut down on development time tremendously.