As part of a project to migrate the PHP code at work from PHP 5.2 to PHP 5.4, I'm using our extensive test suite to look for instances where something that changed between the versions of PHP that we are using has caused some unexpected behaviour. In one of our code bases, I found some tests that are exhibiting a test smell through their use of a try / catch block in the test itself.

He includes a (contrived) example showing the use of an exception in a unit test to run an assertion in the "catch" for the test to pass. He points out that this particular check is being done to see if the user input is valid...and that it's a bad way to enforce it using exceptions. He also suggests that if you have an "if" situation, don't use one test with logic in it, write two tests. He mentions a disenting opinion but notes that a failing test is a failing test, regardless of what caused the failure.

In order to obtain a turing-complete programming language, that is, a language in which we can implement and execute any arbitrary algorithm, that is, that other turing-complete machines can execute too, we now need to add a way of (conditionally) branching, that is, the IF statement, and at least one way of repeating statements, that is the WHILE or the DO WHILE statements.

He includes a simple TL-based script as an end goal for the compiler to be able to execute and shows how to add rules for it to the lexer/parser. Rules for the "if" are relatively simple, but there's a hitch in dealing with embedded "while" statements he had to work around. The post ends with the bytecode results for the sample program and the resulting output from the compiled versions execution.

You're probably already familiar with PHP's if statement. It's very similar to its counterparts in many other programming languages and represents one of the most fundamental concepts in programming. [...] But there's a way to build on this concept and increase your $coolFactor a bit in the process. Allow me to introduce you to the ternary operator, which serves as a shorthand notation for if statements.

They introduce the ternary operator's syntax, the ":" and "?" operators and includes a few pieces of code showing its use. Thankfully they also include a warning - don't overuse or abuse it...and especially don't nest them - that just leads to headaches.

n any given computer language (PHP is no exception) there has to be a way to allow the running code to decide between doing 2 different things. If there wasn't then software would not be able to adapt based on operating conditions, or it wouldn't be able to decide between two different users.

They look at using: if statements and operators, for loops and while loops. When they look at the operators, they talk about the differences between equals/not equals, grater than/less than and two of the boolean operators - AND and OR.

PHP offers an alternative way to write their control structures for as long as I've remembered. It basically does away with the curly brackets and replaces the opening curly with a colon (:) and the closing with '˜end'-whatever. I have to be honest and say I've never really found a need to use the alternative syntax, simply because I'm so used to using the curly braces after so many years of using PHP. Plus, it's less typing!

The one specifically mentioned deals with "if" evaluations. There's two other options to the usual braces method - one being a shorthand using colons and a semicolon and the other using the ternary syntax.

I got curious about which is actually more efficient at matching a random integer with a set of conditionals. So, I setup a script to create a set of large scripts to test the speed of these different constructs. Using the 'time' command, I measured the speed at which the condition could match a random number.

His results found that the switch statement is generally more than 2 times as fast at matching a simple integer. His tests, however, didn't go through much more than this simple test. It'd be interesting to see what it would do with something more complex (like longer strings or handling the result of an evaluation inside the definition of the switch().

Those are 4 typical errors I introduced in my code, and spend some time debugging it, because I found them really hard to spot. Luckily, once I spotted the actual bug, I find it a lot easier the next time the typo occurs. Therefore I want to share those, so that I may save you some minutes of your life hunting stupid bugs.

His three contributions concern a "missing if", the addition of a random semicolon, operator precedence and a for loop that refuses to work. Others have contributed to the comments on the post as well.

We discussed statements briefly in our last article and even got a sneak peek of an IF-statement. Sure I mean, the image was blurry, and the moment it saw us it ran off into the forest. But we saw it. Honest. So in this article, we're going to take a much closer look at PHP statements and even start learning about loops.

They cover if statements (as mentioned) as well as introduce you to its companions, else and else if. The finish off the article with a brief look at one of the simpler loops, the for loop.

Making mistakes is human, and so is fixing them. In your day-to-day programming adventures, it's inevitable to introduce bugs in your PHP code, especially when you're writing very complex applications with tens of thousands of lines of code spread across tens of files.

In this article they look at things like flattening if statements, spplitting single commands across multiple lines, and the difference between =, ==, and ===.

In my recent post on 'Ajax; Templating; and the Separation of Layout and Logic,' I refer to an Ajax Handler that sits server side to handle Ajax calls. Some elaboration is in order.

As I have stated in the past, I'm a huge fan of Prototype AND I choose PHP as my language of choice...so my examples will be using both, but the idea is portable.

His example is a very basic one, pulling in the data from the $_GET values and, with a combination of dynamic function calls and the use of eval(), provides a simple "framework" to handle your Ajax calls. There are two versions of the same thing - one using if statements and the other a switch and various cases.]]> Thu, 23 Mar 2006 12:37:17 -0600