These types of posts have been done ad nauseam, but I’m putting together my own short list for a presentation so I thought I’d share.
They’re not such a big deal in the grand scope of life, the universe and everything, in fact, these are far from the worst missteps you can take in programming.
However, seeing these same problems year after year drives me crazy. It’s like fingernails on a chalkboard.
It makes my soul hurt.
So without further ado, I present to you: My Top 4 JavaScript No-No List
#4 Use semi-colons!
Caution is a word that I CAN understand
There are a couple of well-written articles that defend this lack of punctuation, and they argue their position well. However, I have yet to see a reason NOT to use semi-colons.
Just because you can nitpick the common arguments, blaming bad tools and bad programmers, doesn’t mean that you shouldn’t err on the side of caution.
I’m a firm believe in coding conventions, good un-abbreviated naming, and doing things like always including curly braces after your ifs. The same arguments apply to all, but I think it’s worth the extra effort to provide that extra level of unabiguity.
If these efforts have prevented a single bug, then it’s worth the extra keystroke.
#3 Cache your DOM calls!
It’s impossible to talk about JavaScript, without mentioning jQuery nowadays.
It’s probably just the extra typing, and I’m showing my age here, but I rarely saw repeated document.getElementById-ing.I don’t know what it is about the beloved library that make people think it’s okay to keep $(searching) for the same element.
I cleaned up a function recently that queried the same DOM element 8 times in a single function. That’s 8 times checking the search and 8 times the memory allocation every time that functions called, when only one was needed!
Here’s what I’m on about:
Do This:
var anything = $('#id');
anything.likeThis();
Or Do This:
$('#id').likeThis().andLikeThat();
Just DON’T DO THIS!
$('#id').likeThis();
$('#id').andLikeThat();
$('#id').andLikeThis();
#2 Put it in a file!
- Files are easily minified, saving bandwidth and time
- Files get cached, saving bandwidth and time
- Files make re-use easier
- Files mean less noise in your html templates
- Files keep your behaviors code out of your markup
I’m having a hard time coming up with a con here.
If you need to set server-side variables in your JavaScript then you’re probably doing it wrong. If you need your js in-line then again you’re probably doing it wrong.
Read more about unobtrusive javascript here, and take a few minutes to consider alternative approaches next time you think about breaking this rule.
#1 Avoid Globals!
You knew this was coming, didn’t you.
VAR YOUR VARIABLES
If you don’t var your variables, then you’re writing to the global scope. This means your variables can be written over by anyone else who’s foolish enough to write to the global scope.
You may think that this doesn’t matter. You may think that that your scripts will be the exception, and that they will live and operate in isolation for their enter lifetime. But can you really guarantee that?
And once again, ask yourself what is the downside?
In addition to being safer and promoting encapsulation, it also helps the maintainers narrow down the scope of there debugging. That’s a pretty big pro.
I’ve spent countless hours over the last 10 years tracking down problems caused by overwritten globals, and it’s a problem that’s easily avoided with just three little letters.
In Conclusion
If you take a step back you’ll see that there’s a common theme here, and it applies to any language: Don’t be lazy.
The time you save cutting these little corners is next to negligible, and often lead to really annoying problems down the road. If you’re a professional developer, than you owe it to yourself to take the time to do it right. There are enough problems to contend with, without tripping over our own feet.
PS: Now that I’m off my high horse, I should admit that I’ve learned all of these lessons the hard way, and that I’m still working at it. 🙂
Obligatory Cat Photo