More conditions

More comparisons

You saw this:

< means "is less than." You also saw:

== means "is equal to." As you might expect there's also:

• <= is less than or equal to
• > is greater than
• >= is greater than or equal to
• != is not equal to

They work just as they do in VBA.

Logical operators

In VBA, there's And, Or, and Not. The same in PHP, but the symbols are different.

And is &&. For example, to test whether an animal is long and thin:

|| is or. To test whether a dessert has dark or milk chocolate:

Not is !. If an animal is not a tiger or lion:

Boolean variables

Check these out:

I've taken the test out of the if, and made a variable out of it. The variable will be true or false. That's called a boolean variable.

Booleans can make your code easier to read. For example, suppose your company buys puppies for employees who have worked there for 10 years or more, work in the IT department, are over 50, or are an OU grad. You could put that in one if, like this:

Another way:

I've extracted each test, and given it a name. This makes the business rule easier to understand.

Some business rules are complex. It's easier on your head meat to break them down. If you find yourself getting confused when writing an if, try breaking it down into a simpler test.

Notice the variable names. Booleans tend to start with $is, or $has.

Nesting

Often you end up with ifs inside ifs. That's called nesting.

For example, suppose Shallow Sherri is reviewing a list of potential friends. If the person is young, then OK, they might be friend material. If they're between 30 and 50, they have to have a good income to be interesting, or be well connected. Above 50, they have to have a boatload of cash, and be well connected.

Here's some code for that:

Nesting can make rules easier to think about. When I'm writing the code the lines 15 to 17, I no longer have to think about age. I know this is the code for old people, like me (ewww!). I just focus on that.

Same for lines 9 to 11. I think about the conditions for middle-aged people.

When you get inside the body of an if, you reduce the cognitive complexity of your work. Look for opportunities to make your work easier to think about, when you're writing code.

Notice the variable $isPotentialFriend. It's a flag. It summarizes the results of some processing. Initialize it (line 1), run some code that might change its value (lines 2-19), then check the flag's value (line 20).

Flags are useful things. You learned how to use them in validation, in the VBA course.

Example

Your company makes three products: K32, X64, and F128. You have a few people who field calls about the products. Different people specialize in different things, so you have to route calls, depending on the product and issue.

You can try the program:

http://webappexamples.skilling.us/html/more-conditions/more-conditions.php?product=k32&issue=returns

It takes the parameters product and issue from the URL, and shows output like this:

If missing input, it shows error messages, like this...

... and this...

If the product is unknown, show:

Ol' Man Joe tells you who gets called for what.

(Read in an old, slow cowboy voice.)

Well, I'll tell ya, youngun, but ya ain't gonna like it.

For the K32, well, call Paula Poundstone for a warranty issue. She's right loquacious, she is. Hey, that's be a dang good vocab word. Loquacious. Huh.

Anyways, if the issue is sales or returns, best be talkin' to young Adam the Felber. He done wrote a strange novel awhile back. Weirdest thing you ever read. Though the woman in the beginning was good. Reminds me o' cousin Lucinda. But that's a horse of a different color.

Orange.

You wanna talk about the K32's noise, you talk to Bonnie Burns. Darn woman is a walkin' foley, no lie.

So that's K32 warranty, sales, returns, and noise. Any other K32 issues, you talk to Toni Anita Hull. She's inta extreme cruisin', the biohazard kind.

Now, the X64, that's different. Paula Poundstone handles warranty and noise. Sales, that's Adam the Felber. He sure is around a lot. Always underfoot. Doug the Intern does returns and shippin' for the X64. Maybe the X64 ain't doin' so well. Ain't see young Doug in a while.

Oh, anythin' else about the X64, you ask Toni Anita Hull.

Last, the F128. Well, Paula Poundstone does warranty. Lots to do, there, the 128 is a piece of crap, pardon my French.

Adam the Felber handles noise on the 128. Doug the Intern, he does sales, returns, and shippin'. And, o' course, Toni Anita Hull does all the other F128 issues.

OK, let's write some code. We'll use that error-message-as-flag pattern. You'll see that a lot in this course.

We'll put most of the computation at the top of the PHP page, before doing any HTML output. You'll see that a lot, too.

Let's talk about input and error checking first. There are two GET parameters:

• product
• issue

Both are required. That means there'll be from zero to two error messages. If both are missing, we want two error messages. If one of them is missing, we want one error message. If both are present, no error messages.

First, initialize $errorMessage to MT. Then GET the product:

Recall that isset() is true, if the parameter exists. The if checks for that. If product isn't in the GET, the set $errorMessage. This will act as a flag that something has gone wrong, as well as explain what.

The message has a br tag at the end.

Hmm.

If the product is found, then:

We're going to have a bunch of if soon, checking product to see who to call. Those statements will be easier to write, if we know whether product is upper- or lowercase. By using strtolower(), we know product will be lowercase.

OK, now do the same thing for the issue type.

OK, back to the brs:

Why? Here's what you get if you leave out both GET params:

Both error messages are showing. We want them on separate lines like this.

Here's the HTML we want:

The brs make sure error messages are on separate lines.

Aye! Good on you! In VBA, that might be:

The error messages accumulate in $errorMessage, with a br at the end of each one.

That's so useful, it deserves to be a pattern:

Here's that error code again:

OK, so that's error handling. Now, what about the processing?

Processing

These are nested ifs. The code shows something I mentioned earlier. When writing code, and you're inside an if block, forget about other conditions.

Lines 3-14 are about the K32. When writing that code, I can forget about validation and the other products, and just think about the K32.

Lines 18-29 are about the X64. When writing that code, I can forget about the validation and other products, and just think about the X64.

Lines 33-44 are about the F128. When writing that code, I can forget about the validation and other products, and just think about the F128.

You won't be able to program well, or at all, until you learn to decompose programs. That means breaking a problem into chunks, and work with one chunk at a time.

Plan then zoom

When I write code, I start by outlining the program at the high-level. I use comments. For example, with this program:

It can also help to write down important variables, especially those that link parts of the code. For example:

$errorMessage, $product, and $person link the pieces of the program together.

Next, add in some high-level logic.

Eventually, I'll zoom in on this bit...

... and just do that, pushing the rest of the program out of my head meat. The goal of the code chunk is to work out a value for $person. When I'm write that code, all I think about is working out $person for the K32.

Then I'll zoom out, and zoom in on the next bit...

Learn to reduce the load on your brain is key to Happiness in Programming.

You reduce brain load by zooming in on one part of the program at a time.

Let's make a principle out of plan then zoom.

Learning how to do this makes programming - and many other jobs - easier.

Exercise

todo