scriptNode

I think any programmers worth their weight improve their practices and styles on a regular basis. I've noticed my code has changed drastically in the last year or so. It's more organized, structured, and maintainable than it was, but I've also picked up what I think are some small but good changes:

1. No var in globals (JavaScript)

   I'd be lying if I said I wasn't externally influenced on this one. Douglas Crockford has a lot of great recommendations, and this is one I tend to agree with. When applicable and realistic, making your JavaScript code smaller is always a good thing. It means a faster download for your users which leads to a better user experience.

   // Before: var scriptNode = {}; // After: scriptNode = {};

2. Not abbreviating beyond readability

   This is probably a lesson most programmers learned long ago. I went back to some of my older code recently, hoping to reuse it. The good news was that the code itself was written well enough that I could use it with minimal editing. The bad news was that I first had to figure out what many of the variables were for because they were so badly named:

   // Before: var setCoords = function(c, dir) { var nc = { x : c.x, y : c.y }; if (dir == 'l') { nc.x--; } else { nc.x++; } return nc; }; // After: /** * Set the coordinates based on direction * @param {Object} coords An object with x/y keys * @param {String} dir The direction [l, r] * @return {Object} An x/y object with the new coordinates */ var setCoords = function(coords, dir) { var newCoords = { x : coords.x, y : coords.y }; if (dir == 'l') { newCoords.x--; } else { newCoords.x++; } return newCoords; };

   I'm not suggesting Hungarian notation, but descriptive variable and function names are the way to go. You don't want to hate yourself a month later (or for whoever is working with your code to hate you) when it needs to be maintained later. And thanks to tools like YUI Compressor, even JavaScript files won't be negatively affected by adding a few characters here and there.

3. CSS dashes instead of camelCase

   The logic here is that a language should look like itself. I understand why I used to prefer camelCase; even minified CSS files can't alter class names or IDs, so dashes make for a larger download. But when revisiting a file, it looks less alien when the nomenclature is cohesive. This makes everything easier.

   /* Before: */ .userOptions { font-family: verdana, sans-serif; } div#mainCommentBubble { background-image: url(bubble.gif); } /* After: */ .user-options { font-family: verdana, sans-serif; } div#main-comment-bubble { background-image: url(bubble.gif); }

4. Leaning more towards OO

   Again, I think many programmers have learned this lesson already, and likewise I've been using these practices for a while now. The difference is that my code has become so much more maintainable that I preach these lessons often and have become something of an advocate of these patterns.

   // Before: showError(); toggleElement(content); hideError(); // After: error.show(); content.toggle(); error.hide();

5. Clean, organized MySQL queries

   Thoughout my entire programming career (more than four years now), I have constantly changed the way I organized MySQL queries in my PHP code. Recently I noticed that editing my older code was a pain in the ass, and I sought to change that. Adding a WHERE clause or an extra SELECT parameter should be an easy task, and the solution to me was to break each section into new lines, tabbing in the same manner that I did in my code blocks:

   // Much before: $qry = 'select chats.*, users.username from chats, users where chats.room_id = ' . $room_id . ' and chats.user_id = users.user_id'; // Before: $qry = sprintf('SELECT chats.*, users.username FROM chats, users WHERE (chats.room_id = %s) AND (chats.user_id = users.user_id)', $room_id); // After: $qry = " SELECT chats.*, users.username FROM chats, users WHERE (chats.room_id = $room_id) AND (chats.user_id = users.user_id) ";

6. Using a Single Event Listener When Possible

   Events can be tricky. They can be the cause of memory leaks, and having too many can bog browsers down. So when dealing with multiple instances of similar events, why not combine them? Events are not difficult to parse to figure out what happened to what:

   // Before: var handleClick = function(e) { // Something useful here }; var el, container = document.createElement('ul'); container.id = 'container'; for (var i = 0; i < 10; i++) { el = document.createElement('li'); el.innerHTML = 'List item ' + i; YAHOO.util.Event.addListener(el, 'click', handleClick); container.appendChild(el); } document.body.appendChild(container); // After: var handleClick = function(e) { var el = YAHOO.util.Event.getTarget(e); if (el.nodeName == 'LI') { // Something useful here } }; var el, container = document.createElement('ul'); container.id = 'container'; for (var i = 0; i < 10; i++) { el = document.createElement('li'); el.innerHTML = 'List item ' + i; container.appendChild(el); } YAHOO.util.Event.addListener(container, 'click', handleClick); document.body.appendChild(container);

Small improvements like these can add up to make much better code. If you're a developer and you haven't noticed a positive change in your code in the last few months, I highly recommend reading up on useful patterns and practices.

Read other articles tagged: javascript, mysql, php

Comments (2)

• 
  September 21st, 2008 Binny V A said…

  About the 6th point - you mean you use event delegation method right?
• 
  September 21st, 2008 Matt Hackett said…

  @Binny V A: Yes, and I probably should have used that term since it’s getting pretty well recognized.

Thoughts?

Name: (required)

Website:

Comments: (required)