3 ms·

At least two questions are bad. 7. a = "5"; b = 2; c = a+++b; Why even ask that? It's boring. And operator precedence is not really important in practive, and

by shepik 14y ago

At least two questions are bad. 7. a = "5"; b = 2; c = a+++b; Why even ask that? It's boring. And operator precedence is not really important in practive, and it's bad style and no one writes like that. It's a question for junior-level interview, when you can't ask anything meaningful and (because you have to ask anything) you ask _this_. 9. (16).toString(16) Oh, so Guru should memorize every obscure parameter, shouldn't he? Other questions are fine, though (except 10. Numerical systems, c'mon, it's 2013, not 1980s)

jakub_g 14y ago
Regarding "(16).toString(16)": yep you should know that param and nearly always write myNumber.toString(10) and parseInt(myNumber, 10). JSHint complains if you don't provide the radix. The reason is to not get your ass in fire in production by the fact (016).toString() === "14" (leading 0 means JS guesses a number is in octal representation, unless it contains 8 or 9). And you use JSHint, don't you? If no, install it right now as a pre-build hook. -- EDIT: what I wrote above is bullshit, see the comments below; toString is a different story than parseInt.
- Stratoscope 14y ago
  Sorry, but that advice about number.toString(radix) is mistaken. JSHint does not complain if you omit the radix in a number.toString() call, nor should it. The default radix value for number.toString() is 10, and there are no magical surprises as there are with parseInt(). If you write number.toString() it means exactly the same thing as number.toString(10). There is no reason to provide an explicit radix of 10 unless you just like it better than way. In the (016).toString() example, the problem isn't the missing radix; (016).toString(10) returns the same value, "14". The problem is the 016 constant itself. That is an octal constant and has already been converted to decimal 14 before the .toString() call. There is nothing that .toString() can do to fix this problem. Now you're right that it is useful for a developer to know about the radix parameter, so you can easily convert a number to its string representation in hex or binary or whatever base you need. parseInt() is a different story, of course. You are quite correct that you should never write parseInt(number) without a radix argument, unless you actually want the behavior of a leading zero making it octal and a leading 0x making it hexadecimal. (edited for clarity)
  - jakub_g 14y ago
    I must admit you're right with the first part. I haven't thought twice nor checked things. Thanks for pointing it out. Regaring parseInt(), the story is even more complex though :) You should never use it without the radix because that behavior is not reliable when it comes to implying octal representation. Calling parseInt("016") yields 16 in Chrome (ES5 compliant [1]), while 14 in Firefox, Opera and IE8. [1] https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/parseInt https://developer.mozilla.org/en-US/docs/JavaScript/Referenc...
    - Stratoscope 14y ago
      Oh wow, you're right about parseInt(). For some reason I thought the octal thing was standard across browsers. That's what I get for adding that throwaway comment at the end without checking it. Thanks for catching that!

by shepik 14y ago

jakub_g 14y ago

Regarding "(16).toString(16)": yep you should know that param and nearly always write myNumber.toString(10) and parseInt(myNumber, 10). JSHint complains if you don't provide the radix. The reason is to not get your ass in fire in production by the fact (016).toString() === "14" (leading 0 means JS guesses a number is in octal representation, unless it contains 8 or 9). And you use JSHint, don't you? If no, install it right now as a pre-build hook. -- EDIT: what I wrote above is bullshit, see the comments below; toString is a different story than parseInt.

Stratoscope 14y ago
Sorry, but that advice about number.toString(radix) is mistaken. JSHint does not complain if you omit the radix in a number.toString() call, nor should it. The default radix value for number.toString() is 10, and there are no magical surprises as there are with parseInt(). If you write number.toString() it means exactly the same thing as number.toString(10). There is no reason to provide an explicit radix of 10 unless you just like it better than way. In the (016).toString() example, the problem isn't the missing radix; (016).toString(10) returns the same value, "14". The problem is the 016 constant itself. That is an octal constant and has already been converted to decimal 14 before the .toString() call. There is nothing that .toString() can do to fix this problem. Now you're right that it is useful for a developer to know about the radix parameter, so you can easily convert a number to its string representation in hex or binary or whatever base you need. parseInt() is a different story, of course. You are quite correct that you should never write parseInt(number) without a radix argument, unless you actually want the behavior of a leading zero making it octal and a leading 0x making it hexadecimal. (edited for clarity)
- jakub_g 14y ago
  I must admit you're right with the first part. I haven't thought twice nor checked things. Thanks for pointing it out. Regaring parseInt(), the story is even more complex though :) You should never use it without the radix because that behavior is not reliable when it comes to implying octal representation. Calling parseInt("016") yields 16 in Chrome (ES5 compliant [1]), while 14 in Firefox, Opera and IE8. [1] https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/parseInt https://developer.mozilla.org/en-US/docs/JavaScript/Referenc...
  - Stratoscope 14y ago
    Oh wow, you're right about parseInt(). For some reason I thought the octal thing was standard across browsers. That's what I get for adding that throwaway comment at the end without checking it. Thanks for catching that!