How often do you use parseInt()<\/kbd>? Often enough to have run into the unexpected "starts with 0" problem? Have you ever tried: parseInt("08")<\/kbd>, only to get a return of 0? Let's find out why.<\/p>\n To start, parseInt() <\/kbd>accepts a base as the second argument. You may sometimes see plugins use parseInt(number<\/em>, 10), wonder why added this mysterious 10 as a second argument. Or, perhaps you knew about the base parameter, but wonder why the explicitly specify it.<\/p>\n The parseInt("08")<\/kbd> issue identified above is the reason. Computers love base 2, but base 8 (octal) and base 16 (hexadecimal) are also happily received as they are powers of 2. We use the hex base commonly for RGB color and other values, so languages developed a syntax to easily specify the numeric base. In JavaScript, this notation is as follows:<\/p>\n 0xnumber =<\/em> Hexadecimal You can actually use this is a numeric literal:<\/p>\n \tThe octal notation comes as a surprise, especially if you've even been unlucky enough to accidentally precede a numeric literal with a zero. Why JavaScript couldn't use a notation like "0w33", I will never know.<\/p>\n Everything I've said to this point typically does not present an issue in everyday JavaScript. However, when you introduce user input and other string values, our old friend parseInt()<\/kbd> comes to the rescue, but not without terms. A user will never type 0xFF in place of the base 10 number 255. But, if a user is asked for their birthday, and they use "08" to represent the month of August, we now have an octal number! What's worse, an octal number that is invalid (there's no 8 in the octal base).<\/p>\n And, that concludes the very long winded rationale for always adding the number base parameter 10, when you are converting strings to integers.<\/p>\n <\/p>\n I'll be brief with this one, as I assume most people know about this. However, I still see quite a bit of JavaScript floating around that suggests using "quoted" code within the setTimeout()<\/kbd> function:<\/p>\n I can't say for sure, but everything I know about JavaScript tells me that setTimeout()<\/kbd> will be performing an eval() on the quoted code, which we know is inefficient.<\/p>\n setTimeout()<\/kbd> can, and should be given a function as it's first argument:<\/p>\n <\/p>\n The this<\/kbd> keyword provides a reference to the current object, it provides context. But, we lose that context when we make a call to another function. How often do you find yourself doing this:<\/p>\n In this case, once we stepped inside the inner function, doSomething(), we lost all context that this <\/kbd>provided. But, we were able to maintain that context, by storing it in a local variable called _this<\/kbd>.<\/p>\n I don't know if I'd call this a bad practice, I see it a lot, it works, but perhaps doesn't do a good job of explaining what _this<\/kbd> is. Perhaps the variable should be named something more appropriate, like:<\/p>\n But, there's a way we can avoid this temporary reference to the this<\/kbd> context. We can do this by using the built-in call()<\/kbd> method.<\/p>\n
\n\t0number<\/em> = Octal<\/p>\nx = 0xF;
\n\t15<\/span><\/code>
\n\t
\n\tx = 033;
\n\t27<\/span><\/code><\/p>\nparseInt("08")
\n\t0<\/span>
\n\t<\/code><\/p>\nparseInt("08", 10)
\n\t<\/code><\/p>\nTime out, I see something eval<\/em>() happening here<\/h3>\n
setTimeout('do = "this"', 3000);<\/code><\/p>\nsetTimeout(function() { do = 'this'; }, 3000);<\/code><\/p>\nCan't touch this<\/em><\/h3>\n
(function() {
\n\t var _this = this;
\n\t doSomething() {
\n\t console.log(this); \/\/ this is no longer meaningful - it doesn't refer to the original object
\n\t _this.value = 'I had to copy this to a local variable so I still have a reference to it';
\n\t }
\n\t
\n\t doSomething();<\/code>
\n\t})();
\n\t<\/code><\/p>\nvar myParent = this; \/\/or
\n\tvar myCaller = this;
\n\t<\/code><\/p>\n