In the example in the last chapter example—a web form that lets users run SQL against a MySQL database—you did one of the most common things programmers do. You wrote code that solves a problem, but it’s ugly, messy, and a little hard to understand. Unfortunately, most programmers leave code in that state. That’s something you want to avoid.
Bad code is like sloppy plumbing or a poorly constructed house frame. At some point, things are going to go bad, and someone is going to have to fix problems. And, if you’ve ever had an electrician tell you what he has to charge you because the guy who did the work initially did it wrong before, you know how expensive it is to fix someone else’s mistakes.
But here’s the thing: Even good code is going to fail at some point. Any time you have a system that involves humans, at some point, someone will do something unexpected, or maybe just something you never thought about dealing with when you wrote your code. And that’s when you’re the electrician, trying to fix things when the customer’s unhappy—but in this scenario, there’s nobody else to blame.
So, writing ugly code that works really isn’t an option. At the moment, the code in run_query.php right now is very ugly. It’s all those
if statements that are trying to figure out whether the user entered a CREATE or an UPDATE or an INSERT, or maybe a SELECT…or who knows what else? What you really need is a way to search the incoming query for all those keywords all at once ...