때때로, JavaScript의 type coercion은 유용할 때가 있다.

var myVar = "1.234"; // string 
+myVar; // 1.234 
typeof +myVar; // number 
(+myVar).toFixed(2); // "1.23" string 

하지만, String을 다룰 때는 주의가 필요하지.

String("1.234") instanceof String; // false 진짜? 
(new String("1.234")) instanceof String; // true 어디보자... 
String("1.234") == (new String("1.234")); // true 설마? 
String("1.234") === (new String("1.234")); // false 그렇군. 
 
(function(){return 2*3;}).toString() === (function(){return 6;}).toString(); // true in FF & Opera, false in IE & WebKit 

이쯤 되면 다음과 같은 결과도 미리 예상해 볼 수 있다.

0 == "0"; // true 이젠 안 속아. 
0 === "0"; // false 그렇지. 

세상 속 사실로 알려진 명제도 JavaScript의 요지경 속에 한 번 빠지면,

3 > 2 > 1; // false 

이것은 아래와 같은 true의 변심에서 시작되었음을 알 수 있다.

(true + 1) === 2;​ ​// true 
(true + true) === 2; // true 
true === 2; // false 
true === 1; // false 

어디 한 번 JavaScript의 요지경 속으로 빠져 봅시다! (⊙﹏⊙)

아래 코드를 이해하려면 JavaScript 만의 특성이 가미된 scope과 closures 이해하고 있어야 한다.

function add (x) {
  return function (y) {
    return x + y;
  };
}
var add5 = add(5);
var no8 = add5(3);
alert(no8); // Returns 8 

JavaScript를 좀 더 깊게 이해하고 좋은 코드를 짜기 위해서는 꼭 알고 있어야 할 부분이지만, 처음 접하는 사람들에겐 난해하기 마련인데, 마침 Robert씨가 알기 쉽게 풀어서 설명해 놓은 글을 올려놓았다.

더불어서, 위 소개 글에서도 잘 설명되어 있는 JavaScript Module Pattern을 약간 변형시킨 것으로, 스크립트 사용 용법이 좀 더 일관되고 패턴 속의 어떤 함수와 변수가 공개적으로 접근 가능한지를 훨씬 명확하게 보여주는 Revealing Module Pattern도 참고할 만하다. 이 패턴은 원한다면 실제 private 함수를 좀 더 명확한 이름을 지정해 놓고 공개해서 되돌려줄 수도 있는 장점이 있다.

비록 현재 왕성한 액션 히어로의 역할로 웹의 커다란 한 부분을 담당하고 있는 JavaScript라도 그 결점은 있기 마련이고, 언젠가는 이러한 언어 설계상의 오류가 자기의 뒤통수를 때릴 때가 있을 것이다. 결국, 미리 알아서 조심해야지.

JavaScript에서 NaN 값은 not a number라는 뜻으로, 즉 숫자가 아니라는 의미이다. 하지만,

typeof NaN === 'number' // true 

이렇듯, typeof로는 NaN와 숫자를 구분할 수가 없거니와, 자신과의 비교도 불허한다.

NaN === NaN    // false 
NaN !== NaN    // true 

결국, JavaScript에서는 숫자와 NaN를 구분하는 isNaN라는 함수를 제공하고 있다:

isNaN(NaN)       // true 
isNaN(0)         // false 
isNaN('oops')    // true 
isNaN('0')       // false 

결국, 숫자를 구별하는 가장 확실한 방법으로 다음과 같은 함수가 쓰일 수 있겠다:

function isNumber(value) {
  return typeof value === 'number' && isFinite(value);
}

typeof 얘기가 나와서 그러는데,

typeof null     // object 

null 대신에 object를 돌려받는다. 그래서, null 값을 알아보기 위한 가장 좋은 방법은 아래와 같다:

my_value === null

또한, JavaScript의 Reserved Words는 보통 변수 이름으로 사용될 수 없는데, 굳이 reserved words를 object literals의 키 값으로 사용하려 할 경우에는, 항상 따옴표도 함께 써줘야 하고 dot notation 대신에 bracket notation을 사용해야 한다:

var method;                // ok 
var class;                 // illegal 
object = {box: value};     // ok 
object = {case: value};    // illegal 
object = {'case': value};  // ok 
object.box = value;        // ok 
object.case = value;       // illegal 
object['case'] = value;    // ok 

JavaScript는 프로그램 상 오류를 자동 수정하려는 성질이 있어서 문단 마지막에 항상 semicolons을 삽입하는데, 이것이 오히려 아래처럼 뜻하지 않는 문제를 일으킬 수도 있다.

return
{
  status: true
};

return 뒤에 바로 semicolon이 붙어버리면서 결국, undefined 값을 돌려주게 된다. 그래서 { 는 항상 아래처럼 앞 줄의 맨 마지막에 붙여주는 스타일을 손에 익혀야 한다.

return {
  status: true
};

그리고 string을 integer로 바꾸어주는 parseInt 함수를 사용할 때는 항상 radix 매개 변수를 사용하는 버릇을 들여서, 아래와 같이 뜻하지 않는 결과를 초래하는 일을 미연에 방지한다.

parseInt("08");      // 0  
parseInt("09");      // 0 
parseInt("08", 10);  // 8 

또 하나, JavaScript의 소수점 계산은 형편없는 것으로 악명높다:

alert(0.1 + 0.2); // 0.30000000000000004 

이것은 JavaScript만의 문제가 아니라, Binary Floating-Point Arithmetic(IEEE 754)을 채용한 언어들에서 공통적으로 나타나는 문제점으로, ECMAScript 4에서는 Real Decimals의 채용하면서 이를 극복할 수 있는 문제지만, 당분간은 미리 scaling 해서 이 문제를 피할 수 밖에.

다음은 JavaScript에서 사용되는 여러가지 “falsy” 값들이다:
0(Number), NaN(Number), ”(String), false(Boolean), null(Object), undefined(Undefined).

모두 “falsy” 값을 가지지만 번갈아 서로 혼용되서 사용될 수는 없어서, 예를 들어 null 값을 구하는데, undefined를 대신 사용하면 잘 못된 결과를 얻게 된다. 이 얘기는 자동 타입 변환(type coercion)을 일으키는 == 연산자 대신에 더 염격한 === 연산자를 사용하라는 얘기와 맞닿아 있다.

이 외에도, 실수든 혹은 필요에 의해서든 상호 운용성을 떨어뜨리는 global variables의 남용 등, JavaScript 문법 검사기인 JSLint를 한번 돌려 본 사람이라면 많은 골칫거리를 떠안게 된다. 하지만, 대부분의 골 때리는 일들은 잘못된 습관에서 비롯되는 경우가 많으므로 평소에 많은 코드를 접하면서 좋은 습관을 들이도록 노력하는 것이 중요할 것이다.

JavaScript에서 사용되는 변수들이 가리키는 객체의 유형은 항상 유동적으로 변할 수 있기 때문에 변수에 담겨있는 객체(Objects)의 유형을 검사(type checking)하는 일은 자주 있으며 그 방법에는 두 가지가 있다.

첫 번째 방법은 typeof 연산자를 사용하는 방법. 이것은 변수에 담겨있는 객체의 유형을 String 값으로 돌려준다.

// Check to see if our number is actually a string 
if ( typeof num  == "string" )
  // If it is, then parse a number out of it 
  num = parseInt( num );
 
// Check to see if our array is actually a string 
if ( typeof arr == "string" )
  // If that's the case, make an array, splitting on commas 
  arr = arr.split(",");

하지만, 이 방법은 Object와 Arrary 혹은 맞춤 Object를 구분하지 못하고 그냥 “object”로 인식하기 때문에 이것을 구별하려면 모든 JavaScript Object들이 가지고 있는 constructor 속성을 확인하면 된다.

var obj = { an: "object" };
var arr = [ an, arrary ];
var myObj = new MyObject();
 
if ( obj.constructor == Object ) alert('This is an object!');
if ( arr.constructor == Array ) alert('This is an array!');
if ( myObj.constructor == MyObject ) alert('My holy object!');

지금까지 일반적으로 JavaScript를 웹 문서에 심어놓을 때 MIME type으로는 다음과 같은 어쩌면 즉흥적이고 통일되지 못한 것들이 사용되어 왔다.

• text/javascript
• text/ecmascript
• application/x-javascript (javascript 앞에 x가 붙은 것은 표준이 아닌, 실험적인 것임을 뜻함)
• text/javascript1.5 (요새 브라우저들은 버전 숫자를 그냥 무시해 버림)
• language=”JavaScript” (HTML 4부터는 지원하지 않음)

그래서 이런 혼란스런 상황을 막으려고 2006년 4월에 Javascript(ECMAScirpt)를 위한 MIME type의 표준(RFC4329)이 마련되었지만, 여러 브라우저들의 표준 JavaScript MIME type 지원은 아직 요원한 상황이다.
(확인해 본 바로는, 지금까지 오직 Firefox 1.5+, Opera 9+, Camino 만이 지원하고 있다.)

Javascript 프로그램은 그 성격상 text 문서로 지정하는 것은 적절치 않으며, 대신 application/javascript 혹은 application/ecmascript(이것을 사용하면 좀 더 엄격한 적용 규칙이 주어진다)를 대신 사용할 것을 권장하고 있지만, 이는 대부분의 웹 브라우저들이 지원하지 않는 한 그 실제 적용은 아직 이를 것이다.

당장은 그냥 서버 쪽 MIME type만 고쳐 둠.