Back to Blog
A
PHP Architect ·

Less Code isn't Always Better

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. http://www.flickr.com/photos/banky177/2099793096/ Released under Creative Commons Attribution licenses.
A

PHP Architect

April 29, 2010

Share

Our Partners

Collaborating with industry leaders to bring you the best PHP resources and expertise

Interested in partnering? Get in touch →