자바스크립트 핵심 가이드 - 코드 가이드

왜 코딩 가이드가 필요한가?

잠시만, 생각을 해보도록 하죠. 이는 @Seungdols의 개인적인 생각입니다.

저는 주로 자바 언어를 사용하는 개발자입니다. 자바는 C와 비롯해 블록 스코프를 지원하는 언어입니다.

대개 이런 형태를 띄게 됩니다.

if ( seungdols.equals("seungho") ){//K&R 스타일

}

if ( seungdols.equals("seungho") )

{

}

위 코드처럼 블록을 감싸야 하는 if, for, while, do-while...etc등등 많습니다. 하지만, 어떻게 스타일을 가져가는가?

또한, 가독성이 걸린 중요한 문제라고 생각합니다.

결국, 개발은 혼자 해낼 수 없습니다. 좋은 프로그램은 명확한 가시성을 갖게 됩니다.

이 말은 곧 가독성이 좋아진다는 말이겠죠 ?

가독성은 같이 일하는 개발자, 혹은 기존 개발된 코드를 유지보수 하는 개발자에게 영향을 줍니다.

물론, 코딩 가이드의 정답은 없습니다만, 다수가 약속한다면, 그것은 기준이 되겠죠 ?

책에서는 자바스크립트는 느슨한 데이터 타입 체크 ( 동적 타이핑 언어 )이므로 컴파일 시에 프로그램에 대한 품질 보증이 어렵기에 엄격한 규칙을 정하고 코딩을 해야 한다 말합니다.

1. 배포 해도 문제 없는 수준의 품질과 깔끔함을 항상 유지 할 것

2. 세미콜론 자동 삽입을 방지하기 위해 세미콜론을 명시적으로 삽입할 것.

그리고 if, while 같은 구문에서 블록을 명시적으로 사용 할 것을 권하고 있습니다. 물론, 자바스크립트는 블록 스코프를 지원하는 언어는 아닙니다만, 명시적으로 코드 가이드를 잡는 것이죠. 바로, 오류를 줄이기 위함입니다.

if( copValue ) 

    one();

    two();

로 코딩 하는 것과 아래처럼 하는 것의 차이가 존재 합니다.

if( copValue ) {

    one();

    two();

}

결론적으로 후자를 선택하는 코드 스타일을 권합니다. 왜냐하면, 전자처럼 블록을 잡아 주지 않으면, 본인이 생각한 것처럼 동작하지 않고, 잘못 인식 될 가능성이 있습니다. 실제 의도한 코드는 다음과 같습니다.

if( copValue ) {

    one();

}

two();

결국, 블록을 작성을 하지 않으면, 문제가 생길 가능성이 농후해집니다.

또한, switch문에서 break;를 빼먹어 항상 다음까지 작동하게 되는 불상사를 막아야만 합니다.

참고로, 자바스크립트에서는 함수에서 사용하는 변수들은 함수의 첫 부분에서 선언하는 것이 좋습니다.

typeof

자바스크립트에서는 해당 변수의 형을 리턴하는 연산자가 있습니다.

typeof 100 //number

위 처럼 사용하시면 되지만, 문제점이 있습니다. 흔히 null을 많이 체킹 하시는데, typeof는 null을 정확히 체크 할 수 없습니다.

고로, digit === null로 검사하면 되지만, 객체인지 null인지를 구분 할 수 없어 아래의 방법을 이용해야 합니다.

if( digit && typeof digit === 'object' ){

}

parseInt

parseInt는 문자열을 정수로 변환해주는 함수입니다. 그런데, 이 함수는 매개변수로 넘어온 값을 변환하다가 ‘문자열’이 있으면 변환을 멈추게 됩니다.

결론적으로 위험한 함수이긴 합니다. 그래서 `parseInt(‘10’, 10)처럼 기수를 지정할 수 있으니 이 방법으로 코딩 하는 것이 좋습니다.

NaN

NaN은 특별한 값입니다. 숫자가 아님을 의미하지만 typeof 연산자를 이용하여 number를 비교하면 참 값이 나오긴 합니다.

그래서 자바스크립트에서는 isNaN이라는 함수를 제공합니다.

가장 추천 하는 방법은 책에서 소개 되었습니다.

var isNumber = function isNumber(value){

    return typeof value === 'number' && isFinite(value);

}

위와 같이 isFinite함수를 같이 사용하는 방법입니다. 해당 함수는 NaN과 infinity를 거부하는 장점을 가진 함수입니다.

​