Eschew Obfuscation

All types programming and software development, including web development and design, have some things in common. A litany of these commonalities is not the scope of this post. However, I would like to stress an oft-forgotten rule, common to nearly every form of development: Eschew Obfuscation!

This rule is something that all Computer Science majors learn in the classroom—or were at least taught.  It's something that all web developers and designers are undoubtedly taught. And yet, the number of slow, cluttered, obfuscated, and even broken websites astounds me! The message behind the humorously obfuscated phrase has gone unheeded by many developers—most notably web developers. (Their work is generally highly visible.)

Unfortunately, there are too many platforms, languages, and pitfalls and not enough global obfuscation eschewing techniques to compile a "universally" comprehensive list. However, I'll touch on a few important things off the top of my head that I've been taught and/or discovered and are easily applied to web development. So, here we go:

• Normalize your data.
  Whether you think database schema, object model, or "what set of arrays do I need?" when you see this point, the policy applies. Make your data represent reality minus the overlap. Remember that any data that is duplicated anywhere needs to be updated in each location when that data changes. (unless each copy is purposefully meant to be different) This applies to objects, arrays, and database tables. Each is capable of "pointing" to a row or instance of another. Use this capability.
• Use recursion when it fits the problem well.
  Some problems have a recursive solution. If that solution happens to be the easiest solution to think about and understand, use it. It will also be the easiest for future developers to understand when they're digging through your code.
• Avoid recursion when it doesn't fit the problem well.
  Don't use recursion because you can make it work or when a similarly simply iterative solution is available. A recursive solution is generally a good deal slower than the iterative counterpart. So, if you're using recursion because it's 1337 or clever, stop! Despite what you may have heard, making your code more difficult, slow, and resource hungry is not very 1337 at all.
• Use the best tool for the job.
  Don't use Perl because it makes you look smart. Don't even use Perl because you have an aptitude with Perl. Use Perl only when you're taking full advantage of it's ridiculously fast regular expression engine on very large blocks of text. Use CSS for styling. Use JavaScript or Flash for user-interaction. Et cetera.
• Do not reinvent the wheel if a good one already exists.
  If there's an existing framework or application that does what you need, use it. If your application relies heavily on user-provided data to select DOM nodes, restyle them, move them around the page, and so forth, use something like JQuery. These types of libraries are usually written and optimized by a lot of intelligent people. It would be silly to forgo using a well-crafted tool that does what you need.
• Don't use a wheel for its bolts.
  Including a library for one, two, or even a small handful of its features is often a horrendous waste of bandwidth and an efficiency hit. Do NOT use JQuery solely—or even mostly—for the ability to select nodes by ID using the $ function. Use the methods that the DOM already provides or write your own $ function that does precisely and only what it needs to do.
• Give "things" to your future programming staff and your end-users in small, hierarchical chunks.
  Your navigation, content, and code should be hierarchical, each chunk containing only a "handful" of information, which may reference and/or be part of other chunks. Each chunk should be a complete thought or process, able to be understood, proofread, optimized, or debugged on its own. This will help ensure maintainability, efficiency, and good end-user experience.
• Write and design so that 5-year ago you could understand what you've done.
  This may be hyperbole. But, as you become a "better" developer, your coding style will naturally become more complex. You will find neat ways of doing things you hadn't thought of before. You will find new ways of combining lines of code. You will more effortlessly throw complex chunks of code together in complex ways, and so forth. However, if your previous self would not be able to readily understand your current code, there is high probability that your code is both inefficient and difficult to maintain. Remember, while you grow more sophisticated, the compiler (or parser) is still a relatively stupid thing, designed and optimized for simplicity. The same is probably true of your successors. :-)

Take all of these thoughts with a grain of salt, of course. There are often trade-offs between solutions—even the general guidelines themselves. Is it really more simple to rewrite bolt X or to just use the wheel for the particular bolt? It depends on complexity of the wheel and the bolt. And sometimes a more complex seeming solution will yield significantly better results in some area. But, you ought to show significantly increased benefits before choosing a solution over a simpler solution.

Simple is easy to create, easy to maintain, and easy to look at. But, don't stress out if you can't simplify a solution. Remember, sometimes the simple solution is merely the simplest of several complex solutions. Do your best!

Now, go forth and Eschew Obfuscation!