Yesterday we talked about bad CSS. Today, we're going to talk about bad HTML.

Corey inherited a web page that, among other things, wanted to display a bulleted list of links. Now, you or I might reach for the ul element, which is for displaying bulleted lists. But we do not have the galaxy sized brains of this individual:

There is a surprising amount of debate about how to use CSS classes. The correct side of this debate argues that we should use classes to describe what the content is, what role it serves in our UI; i.e., a section of a page displaying employee information might be classed employee. If we want the "name" field of an employee to have a red underline, we might write a rule like:

.employee .name { text-decoration: underline red; }

Once upon a time, I was tuning a database performance issue. The backing database was an Oracle database, and the key problem was simply that the data needed to be partitioned. Great, easy, I wrote up a change script, applied it to a test environment, gathered some metrics to prove that it had the effects we expected, and submitted a request to apply it to production.

And the DBAs came down on me like a sledgehammer. Why? Well, according to our DBAs, the license we had with Oracle didn't let us use partitioning. The feature wasn't disabled in any way, but when an Oracle compliance check was performed, we'd get dinged and they'd charge us big bucks for having used the feature- and if we wanted to enable it, it'd cost us $10,000 a year, and no one was willing to pay that.

As oft stated, the specification governing email addresses is complicated, and isn't really well suited for regular expressions. You can get there, but honestly, most applications can get away with checking for something that looks vaguely email like and call it a day.

Now, as complicated as the "accurate" regex can get, we can certainly find worse regexes for validating emails. Morgan did, while on a contract.

So many languages eschew "truth" for "truthiness". Today, we're looking at PHP's approach.

PHP automatically coerces types to a boolean with some fairly simple rules:

• the boolean false is false
• the integer 0 is false, as is the float 0.0 and -0.0.
• empty strings and the string "0" are false
• arrays with no elements are false
• NULL is false
• objects may also override the cast behavior to define their own
• everything else is true

Strings in C are a unique collection of mistakes. The biggest one is the idea of null termination. Null termination is not without its advantages: because you're using a single byte to mark the end of the string, you can have strings of arbitrary length. No need to track the size and worry if your size variable is big enough to hold the end of the string. No complicated data structures. Just "read till you find a 0 byte, and you know you're done."

Of course, this is the root of a lot of evils. Malicious inputs that lack a null terminator, for example, are a common exploit. It's so dangerous that all of the str* functions have strn* versions, which allow you to pass sizes to ensure you don't overrun any buffers.