In most cases, they evaluate the same way. For example, these two statements are equivalent.

if ($x && $y) { ... }
if ($x and $y) { ... }

So what’s the difference?

&& vs And – Is One Quicker?

Initially, I thought there may have been a speed factor. && and || are the traditional logical operators – the ones I used when I learned C++.

Therefore, it would be logical to assume that ‘and’ and ‘or’ are simple conveniences added to PHP. If these have to be re-routed through ‘&&’ and ‘||’ to actually evaluate, there would be a slight performance hit if ‘and’ was used instead of ‘&&’.

I did some benchmark testing to see if this turned out to be true, and there was no appreciable difference in execution time.

I designed a script (here’s the source code if you want to try it yourself) to test ‘&&’ verse ‘and’.

The basic timed task is to compare a set of numbers. In order to ensure that each time the script executed it did the same comparisons, I hard coded five sets of numbers.

if ((1 < 2) && (2 < 3) && (3 < 4) && (4 < 5) && (5 < 6)) {
  }

This was executed 100,000 times and timed. The time was recorded and the entire script was run over 100 times. At the end, an average was taken. The script was then modified to replace ‘&&’ with ‘and’ in the statement, and an average of 100 times was taken again.

The results showed no appreciable difference between using ‘&&’ and ‘and.’ Using ‘&&’ took an average of 0.152 seconds, while ‘and’ took an average of .155 seconds. At a little under 2% variation, I doubt that’s statistically significant.

I did notice that there were a few more outliers in the ‘and’ set – a couple times were slightly faster and a couple times were slightly longer than any of the ‘&&’ times.

Regardless, it appears that there’s no appreciable difference in execution time or efficiency between ‘and’ and ‘&&’.

Precedence in Evaluation

The only difference between the two operators, then, turns out to be their precedence.

As the documentation describes, “&&” has greater precedence than “and”. This is somewhat misleading. An example and some more accurate wording would help illustrate what this means.

This is the example in the documentation.

$g = true && false; // $g will be assigned to (true && false) which is false
$h = true and false; // $h will be assigned to true

The level of precedence between ‘&&’ and ‘and’ is rather irrelevant here. However, they both have different levels of precedence relative to the ‘=’ operator.

‘&&,’ like most operators, is evaluated before the ‘=’ operator. Therefore, the entire expression true && false is evaluated and stored in $g.

‘and’ on the other hand is evaluated after the ‘=’ operator. Therefore ‘true’ is stored in $h and then the expression $h and false can be evaluated.

Is There a Lesson Here?

Yes. Precedence of operators in PHP can be a bit strange.

Normal mathematical operations are normal enough. As expected, multiplication and division are evaluated before plus and minus. The PHP developers remembered the order of operations from middle school math.

However, other operators (like these logical operators) can have unpredictable consequences. Instead of relying on PHP’s hard-coded levels of precedence, you should use parentheses often to make sure that your logic is being evaluated the way you want it to be.

For example, you could fix the ‘&&’ – ‘and’ discrepancy with a set of parentheses.

$g = (true && false);
$h = (true and false);

Now we have explicitly told PHP to evaluate the ‘and’/'&&’ expression first and then assign a value to our variable. Likewise, you could use a set of parantheses around $h = true to revert to the other order of evaluation.

While you may understand these obscure rules, not everyone who comes along will. To prevent confusion in the future and needless headaches, tell PHP how you want expressions to be evaluated. Don’t let it decide for you.

While I don’t agree with all of the author’s points, it’s an interesting list of php coding habits to avoid – but that most of us tend to pick up anyway. Here’s a list of my five biggest pet peeves.

5. Output Information Directly in Functions

This is pretty annoying when it’s unexpected. I installed a WordPress plugin (wp_time_since), and I expected it to return a value to me. I ran into some weird outputting difficulties when I tried to echo the plugin output.

After a few minutes I figured out that the plugin was echo’ing the output for me – instead of letting me store it and output it myself. Give me the information, and let me worry about outputting it.

4. Use $_GET When $_POST Would Be Better

There are appropriate places to use $_GET – such as search queries and simply fetching information from a database. However, any time you’re modifying something in the database you should be using a post method and the $_POST array.

This isn’t 100% safe since people can still spoof your script with their own form or a simple http header request, but at least it prevents the average user from accidentally putting random stuff in the URL and screwing up your day. Use the request superglobal arrays wisely. They’re divided into two separate arrays for a reason.

3. Return HTML, not Data, Strings, or Objects

This kind of goes along with #5. It’d be nice if your function gave me raw output, so that I could style and structure it the way I want to. If nothing else, I’d like to wrap the text in my own paragraph tag, in case I want to give it a class.

2. Misuse Object Oriented Programming

For a lot of web-script programmers, OOP is a strange beast. Why? Because it’s new to PHP.

I come from a C++ background, and OOP is pretty natural to me. Therefore it’s annoying when OOP is misused and abused. It’s not simply a container for functions. You should appropriately use private/public methods. It should make some kind of sense, in an “object” kind of way.

Otherwise, just stick with procedural programming. It’s still a valid way of creating your script – and it may just be simpler.

1. Not Clearly Commenting Code

I hate this. I really, really hate this.

Code should be clearly commented and documented. If I’m wading through the API of a large project, I want a narrative of what the function is doing, what the parameters should look like, and what I’m getting in the end. I don’t have all day to figure out your script – so tell me what it’s doing.

Lastly, there’s one thing he mentions that I really don’t agree with.

The author suggests that templating engines (like smarty) are a waste of time. I originally wondered what the purpose of them were, until I used it to build a module for CMS Made Simple.

Templating engines can be very helpful tools to structure and style your output. They’re also terrific if you want to break down the developer/designer tasks. The developer is responsible for fetching and creating the output, and the designer takes the pre-defined Smarty (or template) variables and places them in the template where they need to be.

I can see why some people wouldn’t like them for small tasks, but they can be immensely helpful. Work with them for a while before you pass judgement.

The Pyramid illustrates the different activities that someone generally engages in while learning to program. While looking at the pyramid, I thought, “Do I do all these things?”

For the most part, I do on a daily basis.

Writing About Code and Writing Code

I spend a decent amount of timing writing about code – or thinking about writing about code. That’s a lot of what this website is about, and it’s also why I spend a lot of time on forums like DaniWeb and Digital Point.

As a high school teacher, I know all too well that you learn best by teaching. So I spend a lot of timing writing about what I’m trying to figure out – so I can help others learn it, but also so I can figure it out myself.

On the pyramid, “Writing About Code” and “Writing Code” are separated into two different categories – but for me they’re pretty synonymous. If I spend time writing some code, I usually devote some time to writing about it. It helps me gain a deeper understanding of what I did.

Reading, Revising, and Reading About Code

Likewise, the pyramid divides these into three different tasks – but I’d say they mostly occur at the same time for me.

I spend a lot of time trolling around the PHP sections of webmaster forums (like DaniWeb, DigitalPoint, etc). I like to see what problems other people are having… and then try to solve them.

In the process, I generally end up reading someone’s code, fixing errors in it, and searching the internet to solutions to deeper problems. A small problem in a forum post can easily drive me to learn more about a topic I didn’t know a lot about.

For example, someone posted a question about using preg_replace(). I never used the function much, because I never had a reason to use it over str_replace(). Instead of directing the person to str_replace() like most other respondents did, I spent some time learning how to use preg_replace() and I fixed the error in the original poster’s code.

Reading Environmental Code

If there’s one thing I hate, out of all the bits included in the pyramid, it’s reading environmental code.

For example, I operate another site using CMS Made Simple (Babel). I wrote some modules for the website to make it do exactly what I wanted… and that meant spending a lot of time mucking through the CMS’ source code.

Like most projects, the source code was not well commented or documented. The code didn’t follow the highest standards of coding, either, and I found myself wanting to stop and fix little problems in it as I went.

No, I definitely find it an annoying chore to read through someone else’s code when it’s not well-written and well-documented. That’s part of the reason I always try to make my own code as clear as possible, with documentation throughout.