php[architect] logo

Want to check out an issue? Sign up to receive a special offer.

Less Code isn't Always Better

Posted by on April 29, 2010

If I had more time, I’d write a shorter letter.
~ Mark Twain… T.S. Eliot.. Blaise Pascal… well, someone.

Everyone says “I could build that in an afternoon/weekend/marathon session of caffeine-fueled code-debauchery” but to actually do something well, unsurprisingly, it usually takes longer. I couldn’t help but think of both of these things as I explored a new PHP forum script from Blake O’Hare over at Nerd Paradise. It’s a simple forum system in under 1KB of code. Yes, only 964 bytes according to his count.

To be blunt, it’s not pretty and doesn’t have many features, but honestly, I fluctuate between terrified and impressed by the feat. I’m terrified because if new PHP developers explore this code and believe a Perl-style of “one line to rule them all” and short tag mess is the standard, we’re in trouble.

To all PHP developers: this is not an example of how PHP should be written. This script was an experiment only, but what you can learn from the experiment impressed me:

First, Blake chose a couple of key features to implement and stuck with those. He’s probably had requests for more features and criticism for not having the “useful” things, but sticking to the requirements for the first version is an accomplishment in itself. He prioritized and executed on those priorities.

Next, he practiced simple but effective security techniques. Since “allow HTML formatting” was not in his feature set, he didn’t worry about the messes that come with selective strip_tags and the like. He simply uses htmlspecialchars and nl2br and moves on.

Next, he used single and double quotes in the appropriate places to leverage their strengths. Instead of string concatenation, he counts on variable interpolation to shave character count. It’s not always clear, but it is effective and shows the power of each.

Finally, he uses simple language constructs and concepts. The logic of the script – once you add linebreaks and rename variables – is quite clear. As much as OO principles and Design Patterns are good and useful, they’re often used for evilness that results in mis-direction and obfuscation.

And the criticisms are almost too obvious to note, but I probably should:

  • Short tags (<?) can be a problem if you interact with XML and many hosting providers will have them off anyway, so although not wrong, they’re not recommended;
  • Linebreaks are your friend and should be used when appropriate;
  • Other than simple counters, single letter variable names are not acceptable;
  • Using $_REQUEST instead of $_GET, $_POST, or $_COOKIE hides where the values are provided – while this isn’t problem in this case, it useful to know and limit which methods can perform which actions. For example, a $_GET shouldn’t delete.
  • Mixing business logic and database logic and presentation makes for messes, as it does here;
  • This is a script and not a system, so there’s no reasonable way to extend it to add users, theme it easily, or add all of those other features that “make” it a forum.

More than anything, it’s refreshing and fascinating to see what someone can do when they set clear, simple, direct priorities and focus exclusively on those. As I’ve pondered this, it’s impossible to miss where I’ve drifted from the requirements in my own code and wonder if this scope creep was necessary or optional.

And for the record, this writeup is 4x longer than the code.


Photo courtesy of M Anima. Released under Creative Commons Attribution licenses.

Keith Casey currently serves as Director of Product for working to make APIs easier, more consistent, and help solve real world problems. Previously, as a developer evangelist at Twilio, he worked to get good technology into the hands of good people to do great things. In his spare time, he works to build and support the Austin technology community, blogs occasionally at and is completely fascinated by monkeys. Keith is also the author of “A Practical Approach to API Design” from Leanpub.
Tags: ,

Responses and Pingbacks

[…] something a bit counterintuitive to what a lot of developers think about their code – less code isn’t always better. Everyone says “I could build that in an afternoon/weekend/marathon session of […]

This is like analyzing the form and technique of a drunk frat boy diving off of his house with a beer helmet on a 20 dollar bet.

Same style of code challenge, the smallest MVC framework make a front controller fits in a tweet.

This kind of code must be taken as a style exercise, and not used for real life and production env

[…] a white list to better catch malicious behavior. As my fellow blogger Keith Casey reminded us, less code isn’t always better—and when it comes to security, that notion is quite […]

On the contrary, there’s plenty of code out there that is frightening because it is so large and overly-complex, that it takes a genius to figure out what is going on, let alone make sure it’s secure. I rewrote one of Paypal’s checkout integration scripts a few months ago. Theirs was roughly 190,000 lines of code. I accomplished the same thing, even adding features, and it was about 500 lines when finished. There is definitely extremes in either direction.

wow. nice job. i like it.

Leave a comment

Use the form below to leave a comment: