자바스크립트 프로그램은 함수에서 모든 것을 처리.

함수는 비트를 옮기고 연산을 수행하기 위해 변수와 연산자를 사용.

코드의 가독성을 높이고 복잡도를 낮추려면 기본 포맷을 정한 후 변수, 함수, 연산자 사용법을 정해야 함.


4.1 변수 선언

  - 변수는 var 문을 이용하여 선언.

  - 자바스크립트에서 var는 스크립트 어느 곳에나 올 수 있고 또 여러 번 사용 가능.

  - 모든 변수 선언은 변수가 선언된 위치와 상관없이 함수의 최상단으로 끌어올려진다.

    -> 이것을 호이스트(hoist)라고 한다.

    -> 이로 인해 개발자들이 코드를 잘못 이해하는 일이 종종 발생.

  - for문에서도 변수 선언은 호이스팅(hoisting) 된다는 사실을 잘 인지하지 못하는 경우 발생.

  - 변수 선언을 하면 함수 최상단으로 변수가 끌어올려 지므로 어디에 선언하는지에 관계 없이 최상단에 변수를 선언하는 것과 같다.

  - 이러한 이유로 자바스크립트에서는 변수를 함수 이곳 저곳에 선언하지 않고 최상단에 한꺼번에 선언하는 스타일을 가장 많이 사용.


4.2 함수 선언

  - 함수 선언도 변수 선언처럼 자바스크립트 엔진에 의해 끌어올려진다

    -> 따라서 함수가 선언되기 전에 먼저 사용가능.

  - 자바스크립트 엔진이 해석하는 방법대로 코드를 작성해야 하므로 함수를 사용하기 전에 반드시 먼저 선언할 것을 권장.


4.3 함수 호출문에 공백 넣기

  - 일반적으로 함수 호출문은 복합문과 쉽게 구분할 수 있도록 함수명과 괄호 사이에 아무런 공백도 입력하지 않는 스타일을 권장

ex)

//좋은 예

doSomethind(item);


//나쁜 예: 복합문 처럼 보임.

doSomething (item); 


//복합문.

while (item) {

    //실행할 코드

}


4.4 함수 선언하고 바로 호출하기

  - 자바스크립트에서는 함수 이름이 없는 익명 함수를 선언할 수 있다.

  - 선언한 익명함수를 변수나 프로퍼티에 대입할 수 도 있다.

 var doSomething = function() {

    //함수 본문

};

  - 익명 함수는 선언과 동시에 호출할 수 있고 또 그 반환값을 변수에 할당하는 것도 가능.

  - 익명 함수 선언문 끝에 괄호를 열고 닫으면 바로 호출 가능.

 var value = functnio() {

    // 함수 본문


    return {

      message: "Hi"

    }

}();

  - 함수가 선언과 동시에 호출되었기 떄문에 변수 value에는 함수가 아닌 객체가 할당됨.

  - 이 패턴은 변수에 익명 함수를 할당하는 것과 상당히 유사해 보이는 문제점 발생.

  - 명확하게 하려면 함수 앞뒤에 괄호를 추가.


4.4.1 strict 모드

  - ECMAScript5부터 자바스크립트 문장을 해석하고 실행할 때 실수를 줄이기 위해 strict 모드가 도입.

  - strict 모드를 적용하려면 프라그마(자바스크립트 전처리기에 내리는 명령)를 추가

    -> "use strict"

  - 단순 문자열로 보이지만 ECMAScript5 자바스크립트 엔진은 이 코드를 만나면 strict 모드를 위한 전환 명령어로 인식.

  - 이 프라그마는 전역으로 사용 가능하며 함수 내부에서만 유효하도록 지역적으로도 사용 가능.

  - 일반적으로 전역으로 사용하는 것은 지양.


4.5 동등 연산자

  - 자바스크립트에서 사용할 때 타입 강제 변환이 일어나 다루기 까다롭다.

  - 주로 ==와 != 연산자를 사용할 떄 타입 강제 변환이 일어남.

    -> 서로 다른 데이터 타입을 비교할 때 타입을 강제 변환. 같은 데이터 타입을 비교할 떄는 변환하지 않는다.

  - null과 undefinded는 ECMAScript 표준에 따르면 같은 값으로 판단

  - 타입이 강제 변환되는 ==와 != 사용대진 === 와 !==를 사용하는 것이 좋음.

  - =-==와 !== 연산자는 타입 강제 변환없이 비교 연산을 수행.


4.6 eval()

  - eval()은 문자열로 된 자바스크립트 코드를 실행하는 함수.

 eval("alert('Hi!')");


var count = 10;

var number = eval("5 + count");

  - eval() 함수 외에도 문자열로 된 자바스크립트 코드를 실행하는 방법이 존재.

  - function 생성자, setTimeout(), setInterval()을 통해 자바스크립트 문자열을 실행 가능.

var myFunc = new Functino("alert('Hi!')");


setTimeout("document.body.style.background='red'", 50);


setInterval("document.title = 'It is now '" + (new Data()), 1000); 

  - 특별한 case가 아니면 eval(), setTimeout, setInterval 사용을 금하자.


4.7 기본 래퍼 타입

  - 기본 래퍼 타입은 String, Boolean, Number 세가지가 존재.

  - 각 타입은 전역 범위를 갖는 생성자가 존재하고 기본 데이터 타입에 해당하는 객체가 존재.

  - 기본 래퍼 타입은 다음 예제처럼 기본 데ㅣ터 타입을 객체처럼 사용할 수 있다.

var name = "Nicholas"

console.log(name.toUpperCase());

  - 변수 name은 객체가 아니고 기본 데이터 타입인 문자열 이지만 마치 객체인 것 처럼 toUpperCase() 메서드 사용 가능.

  - 자바스크립트 엔진에서 String타입으로 새로운 인스턴스를 우리도 모르게 생성하기 떄문이다. 

  - 구글 자바스크립트 스타일 가이드에서는 기본 래퍼 타입을 직접 사용하는 것을 금지.




















자바스크립트에서 if나 for와 같이 "문장"을 사용하는 방법은 두가지

여러 줄을 중괄호로 감싸는 방법과 중괄호를 사용하지 않는 방법

// 나쁜 예. 문법 상 문제는 없지만 권장하지 않음.

if (condition)

    doSomething(); 


// 나쁜 예, 문법 상 문제는 없지만 권장하지 않음.

if (condition) doSomething();


// 좋은 예

if (condition) {

    doSomething();

}


// 나쁜 예, 문법 상 문제는 없지만 권장하지 않음.

if (condition) { doSomething(); }

복합문은 반드시 중괄호를 사용.

한줄에 입력하지 말고 여러 중에 걸쳐 입력. 중괄호가 없으면 오해의 소지 발생.

if (condition)

    doSomething();

    doSomethingElse();


이 코드는 작성자의 의도를 알기 어렵다. 이렇게 작성할 일은 없겠지만, if문 안에 처리를 하려 하였으나 중괄호를 넣지 않은 것인지 doSomething()만 실행할 목적이였는지 분간하기 어렵다. 


다음 모든 복합문에서는 중괄호를 반드시 사용한다.

  if

  for

  while

  do... while

  try... catch.... finally 


3.1 중괄호 넣기

  - 중괄호 위치는 주로 두 가지 스타일로 많이 사용.

  - 첫 번째 스타일은 자바에서 사용하는 스타일

  - 자바 프로그래밍 언어 코드 컨벤션, 크락포드 코드 컨벤션, jQuery 코어 스타일 가이드, SproutCore 스타일 가이드, 구글 자바스크립트 스타일 가이드, Dojo 스타일 가이드에서도 해당 스타일 권장.

  if (condition) {

      doSomethind();

  } else {

      doSomethingElse();

  } 


  - 두 번째 스타일은 복합문이 시작하는 다음 줄에 중괄호를 입력하는 방식

  - 해당 스타일은 비주얼 스튜디오에서 이 방식을 강제화하고 있어 C#에서 주로 사용.

  - 자바스크립트에서는 권장하지 않으며, 구글 자바스크립트 스타일 가이드는 세미콜론 자동 입력(ASI) 에러가 발생할 수 있다는 이유로 사용을 금지하고 있음.

  if (condition)

  {

      doSomethind();

  }

  else

  {

      doSomethingElse();

  }


3.2. 복합문에서의 공백

  - 복합문을 시작할 때 공백을 입력하는 방식은 선호에 따라 결정할 문제.

  - 일반적으로 세 가지 스타일로 복합문에 공백을 입력.

  - 문장 이름, 괄호, 중괄호 사이에 아무 공백 없음.

  - Dojo 스타일 가이드에서 해당 스타일 권장.

  if(condition){

      doSomething();

  } 


  - 괄호를 열기 전과 닫은 후에 공백 하나씩 입력,

  - 크락포드 코드 컨벤션, 구글 자바스크립트 스타일 가이드에서 해당 스타일 권장

  if (condition) {

      doSomething();

  }


  - 시작하는 괄호와 닫는 괄호 앞 뒤에 공백 입력.

  - jQuery 코어 스타일 가이드에서 해당 스타일 권장.

  if ( condition ) {

      doSomething();

  }


3.3 switch 문

  - 초기 switch문은 C에서 시작되어 자바에 영향을 미치고 자바스크립트에 적용되는 과정을 거쳐 포맷이 너무 다양하고 다루기 까다롭다.

  - 문법은 비슷하지만, 자바스크립트의 switch문은 다른 언어와 동작이 다름.

  - 자바스크립트의 switch문은 어떤 타입이든 사용가능, 어떠한 표현식도 case문제 들어갈 수 있음. (다른 언어에서는 기본 데이터 타입과 상수만 사용가능)


3.3.1 들여쓰기

  - 아래와 같은 자바 스타일의 switch문을 대부분 사용.

  switch (condition) {

      case "first":

          // code

          break;


      case "second":

          // code

          break;


      case "third":

          // code

          break;


      default:

          // code

  }

해당 포맷의 특징은 다음과 같다.

  - 각 case 문은 switch문을 기준으로 한 단계 들여쓰기. 

  - 두 번째 case 문 부터 case 문 이전과 이후에 빈 줄을 삽입.

대부분의 에디터가 이 포맷의 switch문을 자동완성으로 지원.

  - 코딩 스타일에 대한 관점이 서로 다르므로 어떤 switch문을 사용하느냐는 모두 선호에 따라 결정할 문제.


3.3.2 다음 case 문까지 실행하는 switch문

  - 또 다른 논쟁거리는 "다음 case문 까지 실행하는 switch문(fall-through)를 허용할 것인가".

  - case 문에서 실수로 break문을 빠뜨려 버그가 발생하는 일은 흔히 발생.

  - 더글라스 크락포드는 이런 실수를 방지하고자 모든 case 문제 예외 없이 break, return, throw문으로 마쳐야한다고 주장.

  - 다음 case 문까지 실행하는 swith문도 다음 예제 처럼 명확하게 사용한다면 좋은 방법.

  switch (condition) {
      // 어떤 로직도 수행하지 않고 다음 case 문으로 넘어간다.

      case "first":

      case "second":

          // code

          break;


      case "third":

          // code

          

          /*falls through*/

      default:

          // code

  }

  - 작성자가 주석을 통해 의도적으로 사용했음을 명확하게 한다면 허용해도 된다고 판단.


3.3.3 default 절

  - 논쟁이 될만한 또 다른 요소는 "switch문제 default 절을 꼭 넣어야 하는가?"

  - default 절에 딱히 수행해야 할 로직이 없을 경우 // no default 주석을 통해 작성자의 의도를 명확하게 표현하면 문제 없다고 판단.

  - 추가로 필요없는 문법을 사용하지 않아 용량 절약.


3.4 with문

  - with문은 실행할 로직의 문맥을 변경

  - with문은 객체 식별자를 명시하지 않아도 특정 객체의 프로퍼티와 메서드를 마치 변수인 것처럼 사용하게 해줌.

  - with문의 목적은 객체 내 프로퍼티나 메서드에 접근 할 때, 개발자가 입력해야할 문자를 줄이는데 있다.

  var book = {

      title: "Maintainable JavaScript",

      author: "Nicholas C. Zakas"

  };


  var message = "The book is ";


  with(book) {

      message += title;

      message += " by " + author;

  } 

  - 위 코드에서 with문은 중괄호 안에서 book 변수의 프로퍼티를 마치 변수인 것처럼 사용.

  - 이때 title과 author의 주인이 어떤 객체인지 알기 어렵다는 문제.

  - 또 어떤 변수가 book의 프로퍼티인지, message는 지역 변수인지도 불명확.

  - 다른 개발자가 이해하기 어려울 수도 있다.

  - with문은 문법 에러가 발생할 확률이 높다 strict 모드에서는 사용할 수 없는데 이는 ECMAScript 위원회도 with문을 더는 사용하지 말아야 하는 구문이라 생각한다는 걸 의미.

  - 크락포드 코드 컨벤션, 구글 자바스크립트 스타일 가이드는 with문 사용을 금지.


3.5 for 반복문

  - for 반목문에는 2가지 타입 존재.

  - 전통적인 for 반복문과 객체의 프로퍼티를 순환하는 for...in 반복문이 존재.

  - 전통적인 반복문 제어하는 데는 return이나 throw문을 사용을 제외한 2가지 방법 존재.

  - 첫 번째는 break문 사용. break문을 사용하면 배열 끝에 도달하기 전에 반복문 종료

  - 두 번째는 continue 문 사용. continue는 반복문 내 로직 수행을 즉시 종료하지만, 다음 요소로 넘어가 순환을 계속 진행.

  - 크락포드의 코드 컨벤션에서는 continue 사용을 금지하고 있음.

  - 크락포드는 continue 보다 조건문을 사용하는 편이 낫다고 말한다.

  - 이유는 더 이해하기 쉽고 실수를 줄일 수 있기 떄문.


3.6 for...in 반복문

  - 객체의 프로퍼티를 순환할 떄 사용.

  - 조건문을 따로 정의하지 않고 프로퍼티를 순환하며 프로퍼티명을 반환.

  var prop;


  for (prop in object) {

      console.log("Property name is " + prop);

      console.log("Property value is " + object[prop]);

  } 


  - for...in 반복문의 문제점은 객체가 소유한 인스턴스의 프로퍼티만 반환하는 것이 아니고 상속 받은 프로토타입의 프로퍼티도 반환한다는 점.

  - 이러한 이유로 for...in 반복문 사용시 hasOwnProperty() 메서드를 사용해 현재 인스턴스의 프로퍼티만 걸러서 사용하는 방법이 좋다.

 var prop;


  for (prop in object) {

      if (object.hasOwnProperty(prop)) {

          console.log("Property name is " + prop);

          console.log("Property value is " + object[prop]);

      }

  }


  - 크락포드 코드 컨벤셔에서는 for...in반복문에는 hasOwnProperty() 메서드를 반드시 사용하도록 명시.

'JavaScript > Maintainable JavaScript' 카테고리의 다른 글

Chapter4. 변수, 함수, 연산자  (0) 2016.09.23
Chapter2. Javascript 주석  (0) 2016.09.06
Chapter1. JavaScript 기본 포맷  (0) 2016.09.03
Part1. 스타일 가이드 라인  (0) 2016.09.03
Maintainable JavaScript 시작.  (0) 2016.09.03

주석 작성은 개발보다는 문서 작성에 가까운 일.

고로, 개발자에게 가장 인기 없고 최대한 미루고 싶어하는 일 중에 하나.

하지만, 전체적인 코드의 유지보수를 위해 주석은 매우 중요.


2.1 한 줄 주석

  - 한 줄 주석은 두개의 슬래시를 이용하여 작성. 그 줄에서 끝남.

  - 보통 두 개의 슬래시를 입력하고 주석을 입력하기 전에 한칸 띄움.

  - 한줄 주석은 3가지 방법으로 사용.

  - 주석을 입력하기 전, 한 줄을 비우고 시작하며 주석은 설명할 코드 바로 윗줄에 작성.

    들여쓰기 단계는 설명할 코드에 맞춤.

  - 한 줄 주석은 꼬리 주석을 입력할 떄 사용. 줄 끝에 입력하는 꼬리 주석은 적어도 한 단계 들여쓰기를 한 후에 입력.

    이 때 꼬리 주석도 최대 줄 길이를 넘으면 안됨. 주석을 입력하기에 공간이 부족하면 코듸 윗줄에 주석 입력

  - 한 줄 주석은 코드를 주석처리 할 떄 사용. 

  - 코드를 주석 처리할 떄를 제외하고, 연속적으로 한 줄 주석 사용은 지양.

  - 주석이 길어지면 여러 줄 주석을 사용.


2.2. 여러 줄 주석

  - 여러 줄 주석은 말 그대로 여러 줄에 걸친 주석을 파일에 입력할 떄 사용.

  - /*로 시작하여 */로 끝남.

  - 여러 줄 주석을 이용해 한 줄만 입력해도 되고, 여러 줄로 입력해도 무방.

  - 여러 줄 주석도 한 줄 주석과 마찬가지로 주석 바로 윗 줄은 한 줄을 비우고 설명할 코드 바로 윗줄에 주석 입력.


2.3 주석 쓰기

  - 주석은 개발자 사이에서 항상 많은 논란을 야기.

  - 일반적으로는 명확하기 않은 것에 대해 주석을 쓰고, 코드 자체로 충분히 설명 가능한 부분에는 주석을 사용하지 않는다.

ex) 나쁜 예

// count 초기화

var count = 10;


//좋은 예


// 이 값을 수정하면, 큰 비가 내립니다.

var count = 10;


  - count 변수의 값을 변경하면 큰 비가 내린다는 말은 황당하지만, 주석이 없었다면 아무도 몰랐을 부분이니 이 주석은 적절하다고 볼수 있음. 

  - 일반적으로 주석은 코드를 명확하게 해야 할 곳에 추가해야 한다.


2.3.1 이해하기 어려운 코드

  - 이해하기 어려운 코드에는 반드시 주석을 추가해야 한다.

  - 코드의 역할에 따라 여러 줄 주석 또는 한 줄 주석을 여러 개 사용하거나 잘 혼용해서 사용.

ex) var mode = 1;  // 1, 2, 3, 4 블라블라

1, 2, 3, 4 중 하나의 값을 가지지만 1, 2, 3, 4가 무엇을 의마하는지 어렵다.

이럴때는 주석이 필수.


2.3.2 오해하기 쉬운 코드

  - 다른 개발자로 하여금 오해를 불어일으킬 수 있는 코드에는 주석 작성.

  - 일반적인 로직에서 벗어난 코드라던지, 특별한 이벤트를 위해 어쩔 수 없이 작성된 코드라던지 부가 설명이 없으면 이해할 수 없는 코드에 작성하면 좋다.


2.3.3 특정 브라우저 핵

  - 특정 브라우저를 지원하기 위해 작성한 코드인 경우 주석 작성.

  - 오래된 브라우저의 경우 크로스 브라우징이 안된다거나 브라우저 간 호환이 되지 않아 이를 처리 하기 위해 작성된 코드에는 주석을 작성하도록 한다.


2.4 문서화 주석

  - 문서화 주석은 기술적으로는 자바스크립트에서 지원하는 영역은 아님. 굉장히 많이 사용됨.

  - 문서화 주석에는 다양한 포맷이 있지만 JavaDoc 문서 포맷을 가장 많이 사용.

  - 여러 줄 주석과 유사하지만, 별표가 하나 더 붙어 /** 로 주석을 시작하고 다음줄 부터 항목 마다 @를 앞에 붙힌다.

  - 주석을 문서화하는 툴킷으로 JSDoc도 존재.

  - JSDoc은 특정 라이브러리에 구애받지 않고 사용가능.

  - 오픈소스 프로젝트에서 많이 사용되고 있으며 구글에서도 사용함.

  - 문서화 주석을 사용할 때는 아래 항목을 모두 만족해야 한다.

모든 메서드

  - 모든 메서드에 대한 설명이 추가. 인자 값이나 반환 값에 대한 설명도 있어야 함.


모든 생성자

  - 생성자에 대한 주석에는 사용자 정의 타입의 목적이 포함. 인자 값에 대한 설명 포함.


주석을 추가한 메서드를 가진 모든 객체

  - 객체의 메서드에 문서화 주석이 추가되었다면, 적절한 문서 생성을 위해 객체에도 주석 추가. 


스타일 가이드의 핵심은 기본 포맷 규칙이다.

규칙에 따라 코드를 어떻게 작성할지 큰 틀에서 정함.

개발자가 팀에서 정한 스타일대로 코드를 작성할 수 있게 안내하는 역할을 한다.

코드를 일관되게 작성하려면 이러한 모든 규칙이 중요.


1.1 들여쓰기

  - 들여쓰기는 거의 모든 언어에서 첫 번째로 결정하는 부분.

  - 탭을 이용한 들여쓰기

한단계 들여쓰기는 탭 한번, 두 단계 들여쓰기는 탭 두번, 이런 식으로 사용.


  * 장점

1. 탭과 들여쓰기 단계가 일대일 대응되어 논리적.

2. 각 텍스트 에디터에서 탭 크기를 원하는 대로 설정할 수 있어 들여쓰기를 좁게 설정하는 개발자나 넓게 설정하는 개발자 모두 원하는대로 볼 수 있다.


  * 단점

1. 시스템마다 탭 크기를 다르게 표현한다는 단점.

  - 에디터나 시스템에서 열었던 파일을 다른 데서 열었을 떄 자신이 보던 방식과 달라 난감할 수도 있다.


이는 개발자 마다 같은 코드를 다른 방식으로 본다는 것이고, 협업에서 좋지 않다. 


  - 공백을 이용한 들여쓰기

2개/3/개/8개 공백 중 한 가지 방식을 이용해서 들여쓰기 하는 것이 일반적.

이 방법은 자바스크립트뿐 아니라 프로그래밍 언어에서 전반적으로 사용.

실무에서는 보통 2/8개의 절충안으로 4개 공백 들여쓰기 사용.


  * 장점

1. 어떤 에디터 시스템에서도 똑같이 보인다는 점.

  - 텍스트 에디터에서 탭 키를 누르면 여러 개의 공백을 입력하도록 설정이 가능.

  - 즉, 모든 개발자가 소스 코드를 동일하게 볼수 있다.


  * 단점

1. 개발자 중 한명이라도 에디터 설정을 잘못하면 서식에 문제가 생길 수 있다.

개인마다 다른 방법을 추구할 수 있지만, 팀 내 의견을 하나로 모으는 것이 무엇보다 중요.

다음은 참고할 만한 다른 스타일 가이드의 들여쓰기 방법.

  - jQuery 코어 스타일 가이드 : 탭

  - 더글라스 크락포드의 자바스크립트 코드 컨벤션 : 공백 4개

  - SproutCore 스타일 가이드 : 공백 2개

  - Dojo 스타일 가이드 : 탭

  - 추천 : 공백 4개

  - 많은 텍스트 에디터에서 탭 키 대신 공백을 사용하도록 설정하면 기본값으로 공백 4개를 사용.

  - 공백 2개로 들여쓰기를 하면 들여쓰기 했는지 구분이 어려울 수도 있다.

Note. 탭으로 하던 공백으로 하던 선호에 따라 다르지만 혼용하여 사용하면 안된다. 



1.2 문장 종료

  - C++이나 자바처럼 C와 비슷한 언어는 보통 세미콜론(;)으로 문장을 종료.

  - 흥미롭게도 가장 혼란스러운 것이 자바스크립트 문장은 세미콜론(;)이나 줄 바꿈으로 끝난다.

var name = "hashmap27";

function sayName() {

    alert(name);

}


var name = "hashmap27

function sayName()

    alert(name)

}


두가지 스타일의 자바스크립트 문장이 모두 유효한 문장이다.

단 아래 문장은 권장하지 않는다. 

  - 세미콜론을 입력하지 않아도 자바스크립트에서는 ASI(Automatic Semicolon Insertion) 메커니즘 덕분에 정상적으로 동작.

  - ASI는 대부분 문제없이 작동. 그러나 ASI가 세미콜론을 찾는 규칙은 기억하기 어려울 정도로 복잡하므로 명시적으로 세미콜론을 넣기를 권장.

  - 일반적으로 ASI가 수행되는 시나리오는 정해져있다. 주로 세미콜론이 없어도 ASI에서 알아서 넣어주겠지 하는 안일한 생각에서 발생하며, 또는 경험이 부족한 개발자가 세미콜론을 빠뜨리는 실수로 인해 발생한다.

  - 더글라스 크락포드 컨벤션, jQuery 컨벤션, 구글 자바스크립트 컨벤션, Dojo 컨벤션 모두 세미콜론 사용을 권장한다.

  - JSLint와 JSHint 모두 기본적으로 세미콜론이 없으면 경고 메시지를 출력.



1.3 줄 길이

  - 줄 길이는 들여쓰기와 깊은 관계가 존재.

  - 코드가 가로 스크롤이 생길 만큼 길면 가독성이 떨어짐.

  - 줄 길이 최대 80자는 다른 언어에서도 많이 사용하는 코딩 규칙.

  - 일반적으로 추천하는 줄 길이

 - 자바 : 소스 코드의 최대 줄 길이는 80자, 문서화 주석의 경우 70자

  - 안드로이드 : 최대 100자

  - 루비 : 최대 80자(비공식)

  - 파이썬 : 라인 당 79자

  - 자바스크립트 스타일 가이드라인에서는 대부분 줄 길이를 정의하지 않지만, 크락포드 코드 컨벤션에서는 최대 80자로 정의.



1.4 줄 바꿈

  - 줄이 최대 글자수에 도달하면 두 줄로 나누어야 하는데 보통은 연산자 다음에 줄을 바꾸고 두 단계 들여쓰기를 한다.

  - ,(콤마)는 연산자이므로 이전 줄에 있어야 한다.

연산자 위치는 ASI 메커니즘과 연관이 있는데 연산자가 다음 줄로 넘어가면 ASI가 자동으로 세미콜론을 삽입할 수도 있어 굉장히 중요하다.

따라서 줄을 바꿀 떄 연산자를 마지막에 찍는 습관을 들이면 ASI 에러를 방지 할 수 있다. 

  - 줄을 바꿀때 한 가지 예외 사항이 존재.

 변수를 다른 변수에 대입할 때 두 번째 줄의 들여쓰기는 첫 번째 변수와 열을 맞춤.

ex) var result = "aaaa" + "bbbb" + "cccc" + "dddd" +

                     "eeee";

이와 같이 맞춘다.



1.5 빈 줄 넣기

  - 빈 줄은 코드 스타일에서 자주 간과 되는 부분.

  - 코드는 하나의 커다란 덩어리보다는 여러개의 문단으로 구성.

  - 적절한 빈 줄은 코드의 가독성을 높힌다.

  - 보통 다음의 경우 빈줄을 추가하는 것이 좋다.

 - 메서드 사이

  - 메서드 내 지역 변수와 첫 번째 문장 사이

  - 한 줄 또는 여러 줄 주석 전

  - 가독성을 높이기 위해 메서드 내에서 논리적으로 구분되는 곳.



1.6 이름 규칙

"컴퓨터 과학에서 가장 어려운 두 가지 문제는 캐시 무효화와 네이밍이다"

  - 필 칼튼


  - 우리가 짜는 코드 대부분은 변수와 함수를 사용.

  - 변수명과 함수명에 대한 이름 규칙은 이해하기 쉬운 코드를 작성하는 데 꼭 필요하고 중요함.

  - 자바스크립트의 기반이 되는 ECMAScript는 낙타 표기법(Camel casing)으로 작성.

  - 낙타 표기법은 소문자로 시작하고 새로운 단어를 사용할 때 마다 첫 문자는 대문자로 입력하는 방식.

  - 일반적으로 자신이 사용하는 언어의 표준 라이브러리에서 따르는 이름 규칙을 사용.

  - 대부분의 자바스크립트 개발자들은 변수명과 함수명을 지을 때 낙타 표기법을 사용.

  - 구글 자바스크립트 스타일 가이드와 SproutCode 스타일 가이드, Dojo 스타일 가이드 모두 낙타 표기법을 사용하고 명시.

Note. 2000년도쯤까지 자바스크립트에서 헝가리안 표기법이 많이 사용 됨.

이 표기법은 변수명 앞에 변수의 타입을 붙이는 방식으로 sName은 문자열을 의미, iCount는 정수형 변수를 의미.

이제는 많이 쓰지 않고, 주요 스타일 가이드에서도 추천하지 않는 표기법. 


1.6.1 변수와 함수

  - 변수명은 낙타 표기법으로 사용, 명사로 시작.

  - 변수명은 명사로, 함수명은 동사로 시작하면 서로 구분하기 용이.

  - 의미를 빠르고 정확하게 전달하기 위해 가능한 한 짧게 정하는게 좋음.

  - 변수명은 변수 이름만으로 데이터 타입을 알 수 있도록 만든다.

ex) count, length, size와 같은 이름은 데이터 타입이 숫자인 것을 알 수 있고

name, title, message 같은 이름은 문자열임을 알 수 있다.

i, j, k같이 한글자로 된 변수는 보통 반복문에서만 사용. 

  - 의미없는 변수명은 사용하지 않아야 함.

  - foo, bar, temp같은 변수명은 다른 개발자가 봤을 떄 전체 코드를 보지 않으면 변수가 어떻게 사용되는지 알 수 없다.

  - 함수명과 메서드명의 첫 번째 단어는 동사로 시작해야 한다.

  - 보통 많이 사용하는 동사는 다음과 같다.

동사

의미 

can

불리언 값을 반환하는 함수 

has

불리언 값을 반환하는 함수 

is

불리언 값을 반환하는 함수

get

불리언 이외의 값을 반환하는 함수

set

값을 저장하기 위해 사용하는 함수

  - 이러한 규칙을 따라는 것이 읽기 좋은 코드를 작성하는 시작점.

Note. jQuery의 함수명은 위에서 설명한 규칙을 따르지 않는다.

jQuery의 많은 메서드가 getter와 setter의 역할을 동시에 하기 떄문. 


1.6.2 상수

  - ECMAScript6 이전까지 자바스크립트에는 상수 개념이 없었다.

  - 있다고 해도 개발자들은 변수를 선언해 상수 처럼 사용해왔다.

  - C에서 사용하는 규칙을 가져와 상수는 모든 문자를 대문자로 쓰고, 단어가 바뀔 떄는 밑줄을 사용.


1.6.3 생성자

  - 자바스크립트에서 생성자는 new 연산자로 새로운 객체를 생성하는 사용.

  - 생성자는 단순한 함수.

  - 자바스크립트에는 Object나 RegExp와 같은 내장된 생성자가 많이 존재.

  - 또 개발자가 새로운 타입을 만들려고 새로운 생성자를 추가할 수 도 있음.

  - 자바스크립트에서 생성자는 파스칼 표기법(Pascal Case)을 사용.

파스칼 표기법은 낙타 표기법과 유사.

낙타 표기법과 다르게 첫 글자는 대문자로 시작한다. 

  - 크락포드의 코드 컨벤션, 구글 자바스크립트 스타일 가이드, Dojo 스타일 가이드 모두 파스칼 표기법을 추천.

  - JSLint는 생성자가 대문자로 시작하지 않거나 생성자 함수가 new 연산자로 시작하지 않으면 경고 메시지 출력.

  - JSHint에서는 newcap 옵션을 추가했을 때, 생성자가 대문자로 시작하지 않으면 경고 메시지 출력.



1.7 리터럴 값

  - 자바스크립트에는 다양한 타입의 기본 리터럴 값이 존재.

  - string, number, boolean, numm, undefinde, 객체 리터럴과 배열 리터럴도 존재.


1..7.1 문자열

  - 특별히 자바스크립트 문자열은 큰따옴표와 작은따옴표 모두 사용 가능.

  - 자바나 PHP같은 언어와 달리 자바스크립트의 문자열에는 큰따옴표나 작은따옴표에 기능적 차이가 전혀 없다.

  - 동작도 완벽하게 동일.

  - 차이가 있다면 문자열 구분자로 역슬레시(\)를 사용하는 점.

  - 큰 따옴표, 작은 따옴표 어느 것을 선택해도 무방하지만 하나만 선택하여 코드 전체에 통일성을 부여해야 한다.

  - 크락포드, jQuery는 모든 문자열에는 큰따옴표 사용을 권장.

  - 구글에서는 문자열에 작은따옴표를 권장.

  - 여러 줄에 걸쳐있는 문자열에 대해 문자열을 여러개로 나눠 합치는 방법을 권장

ex) vae longString = "Here's the story, of a man " +

                           "named Brady."; 


1.7.2 숫자

  - 자바스크립트에서 숫자는 정수, 실수에 상관없이 모든 타입이 숫자 타입에 저장.

  - 다양한 숫자 형식을 표현하기 위해 다양한 숫자 선언 방법을 제공.

//정수

var count = 10;


//십진수

var price = 10.0;

var price = 10.00;


//8진수 - 권장하지 않음.

var num = 010; 


//16진수

var num = 0xA2;


//지수 표기

var num = 1e23;

  - 8진수 포캣 사용은 에러를 유발하고 혼동하기에도 쉽다.


1.7.3 null

  - 보통 null에 대해 잘못 알고 있거나 undefinded와 많이 혼동한다.

  - null은 다음과 같이 한정된 곳에서만 사용해야 한다.

  - 나중에 값을 할당할 변수를 초기화할 때

  - 선언한 변수에 값이 할당되었는지 비교할 때

  - 인자 값으로 객체(Object)를 넘기는 함수를 호출했을 때

  - 함수를 호출한 곳에서 반환값으로 객체(Object)를 기대할 때 

  - 다음은 null을 사용하면 안되는 경우

  - 함수의 인자 값을 확인하기 위해 null 비교.

  - 초기화되지 않은 변수를 null 비교 

  - null은 obejct를 대신한다고 생각하는 것이 가장 좋다.


1.7.4 undefinded

  - 대부분undefinded와 null을 자주 혼동.

  - 이 둘을 잘 구분하지 못하는 이유는 null == undefinded가 true이기 때문.

  - 그러나 undefinded와 null의 사용법은 많이 다름.

  - 초기화되지 않은 변수는 초기 값으로 undefinded를 갖는다. 즉, 변수가 실제 값으로 초기화 되기를 기다린다는 의미.

  - 변수가 선언되지 않았을 경우 typeof 연산자가 undefinde를 반환한다고 생각하면 된다.

  - 변수를 선언하고 값은 나중에 대입하려면 null로 변수를 초기화해야 한다.

  - 변수를 null로 초기화하면 나중에 값을 저장할 것이라는 의도를 명확히 할 수 있다.

  - typeof 연산자는 null에 대해 "object" 문자열을 반환하여 undefinde와 구분할 수 있다.


1.7.5 객체 리터럴

  - 객체 리터럴은 Obejct의 인스턴스를 생성해 프로퍼티를 추가하는 방법이 비해, 간단히 추가할 프로퍼티를 정의하고 바로 객체를 생성할 수 있어 많이 사용됨.

  - 객체 리터럴은 두 개의 중괄호 안에 모든 프로퍼티를 정의할 수 있다.

  - 리터럴을 사용하지 않는 방법에 비해 같은 작업을 더 효율적이고 간단하게 수행.

  - 객체 리터럴 생성 예시

//권장 방법

var bool = {

    title: "Maintainable JavaScript",

    author: "Nicholas C. Zakas"

}; 


//권장하지 않는 방법

var book = new Object();

book.title = "Maintainable JavaScript";

book.author = "Nicolas C. Zakas";

  - 구글 자바스크립트 스타일 가이드에서는 객레 리터럴 포맷을 권장한다.

  - 크락포드 코드 컨벤션에서도 Object 생성자 이용방법 보다 객체 리터럴을 이용하는 방법을 권장한다.


1.7.6 배열 리터럴

  - 배열 리터럴은 객체 리터럴처럼 자바스크립트에서 배열을 간단하게 선언하는 방법이다.

  - Array 생성자 보다 2개의 대괄호를 사용하여 배열의 초기값 설정한다.

//권장 방법

var colors = " ["red", "green", "blue"];

var number = [1, 2, 3, 4];


//권장하지 않는 방법

var colors = new Array("red", "green", "blue");

var number = new Array(1, 2, 3, 4);

  - 구글 자바스크립트 스타일 가이드와 크락포드 컨벤션에서 권장하는 패턴이다.

"프로그램은 우선 사람이 이해할 수 있어야 한다. 컴퓨터에서 실행되는가는 부차적인 문제다."

  - 도널드 커누스


  - 각자 다른 일을 하던 사람들이 모여 처음 한 팀을 이룰 떄는, 코드 작성 방법도 통일되지 않고 제각각이기 마련.

  - 서로 다른 환경에서 일을 해왔기 때문에 코드 작성 방법에 대한 생각이 다를 수 있다.

  - 그러기에 작성 방법을 통일할 필요가 있다.


Note. "스타일 가이드라인" 과 "코딩 규칙"을 자주 혼동하여 사용.

스타일 가이드라인 : 소스 코드의 레이아웃에 초점을 맞춘 규칙.

코딩 규칙 : 프로그래밍 관례와 디렉터리 구조, 주석에 대한 것도 포함. 


스타일 가이드라인은 왜 필요한가?

  - 코드에 일관성이 있어야 더 이상 코딩 스타일 같은 사소한 일로 시간을 허비 하지 않고 깊은 논의가 가능.

  - 코드에 일관성이 생기면 팀에서 다음과 같은 장점을 얻을 수 있다.

  - 작성자와 상관없이 어떠한 파일이든 다른 개발자가 작업 가능.

또한 모든 파일에 일관싱이 있으니 포맷을 다시 맞추거나 꼬여있는 로직을 이해하는 데 시간 낭비할 필요가 없음.

  - 에러가 훨씬 잘 보임. 코드를 일관되게 작성하면 잘못된 부분은 일관적인 흐름에서 벗어나기 때문. 

  - 이러한 이유로 전 세계의 많은 기업이 내/외부적으로 스타일 가이드라인을 공개함.


유용한 툴

  - 코딩 가이드라인은 세우기도 어렵지만, 지키는 것도 굉장히 어렵다.

  - JSLint는 자바스크립트에 대한 일반적인 코드 품질 검증 툴로 더글라스 크락포드가 만듦.

  - 초기 JSLint는 자주 틀리는 자바스크립트 패턴을 찾는 간단한 유틸로 시작. 이후 코드에서 잠재적인 에러를 찾는 것 뿐만 아니라 스타일에 대한 이슈도 경고하도록 발전.

크락포드는 자바스크립트 스타일을 다음 세가지로 나누어 정리.

  - 자바스크립트 스타일 요소 1(http://javascript.crockford.com/style1.html)

    기본적인 패턴과 문법에 대해 다룬다.

  - 자바스크립트 스타일 요소 2(http://javascript.crockford.com/style2.html)

    일반적으로 사용하는 관용구를 다룬다.

  - 자바스크립트를 위한 코딩 규칙(http://javascript.crokford.com/code.html)

    스타일 요소1, 2,를 강조하고 스타일 가이드라인 코드를 추가 


  - JSHint는 JSLint에서 파생. 안톤 코발료프가 관리.

  - JSHint의 목적은 사용자 취향에 맞게 변경할 수 있는 자바스크립트 코드 품질과 스타일 가이드라인에 대한 툴을 제공.

  - 문법 에러를 제외하고 JSHint에서는 거의 모든 경고를 끌 수 있다.

  - 안톤 코발료프는 GitHub의 소스 코드 저장소를 통해 JSHint에 참여하고 기여하길 권장.


= 이러한 툴들은 빌드 프로세스에 포함시키면 코드에 숨어있는 잠재적인 에러도 잡을 수 있고, 코딩 규칙이 자리잡는데 좋은 시작점이 될 수 있다.

Maintainable JavaScript 책 정리 시작.

(읽기 좋은 자바스크립트 코딩 기법)


자바스크립트를 사용할 줄은 알았다.

정말 제대로 된 자바스크립트 코딩이였을까? 라는 질문에

"No. 그냥 대충 기능만 구현되도록 구글링 해서 어거지로 구현했어" 라는 답이 도출 됐다.


현재 앱 서비스의 서버파트 개발을 하고 있지만

Native App의 단점을 보완하고 서버 주도적인 서비스를 구축하고자 Hybrid 방식을 채택하기 시작했다.

(Native App의 단점이라면 한번 배포되면 회수가 불가능하다는 점과 웹 처럼 빠른 수정 및 대응이 불가능하다는 점 등등..)


결국 웹 페이지 작업은 진행해야 했고 깔끔하고 군더더기 없는 소스를 짜고 싶었기 떄문에

해당 책을 추천 받아 읽었고, 그 내용을 블로그에 정리하기로 했다.


지은이 말.

  - 웹 개발의 전문화는 어렵고 복잡한 과정으로 이루어져 왔다.

  - 대기업에서도 웹을 전문화시키는 과정에서 많은 시행착오를 겪어왔다,

  - 소유모의 기업에서 모든 웹 서비스를 혼자 담당하는 사람이면 무엇이든 원하는 대로 가능하겠지만 대부분의 프로그래머가 기업이라는 환경에서 일하게 되면서 혼자 하는 것이 아니라 팀 단위로 작업하는 방법을 알아가야 함.

  - 6년차 이직 이후 팀원들과 다른 방식으로 코드를 짜게 되는 것을 알게 되었고 그것이 문제가 있다고 판단.

  - 팀에 더 도움이 되도록 동료들과 같은 방식으로 작업 시작.

  - 생소한 부분은 그 부분을 잘 아는 동료의 작성 코드를 참고

  - HTML, CSS, 자바스크립트 코딩의 경우 동료에세 패턴을 적용해볼 것을 권하고 이를 표준으로 규정하기 위해 빌드 프로세스에 린트 추가.

  - 결과, 팀은 윤활유가 잘 칠해진 기계처럼 유기적인 업무 가능

  - 이미 익숙해진 프로세스 중에도 항상 옳지만은 않다.

  - 통일된 방법이 없으면 많은 개발자들은 각자의 방법대로 처리하고 그 결과 버그로 이어지기도 함.

  - 이 책은 '개인이 아닌, 팀의 일원으로 자바스크립트 코드를 작성하는 방법'에 관한 책이다.

  - 우리는 코드를 유지보수하는 데 대부분의 시간을 보내고 있다.

  - 동료에게 "우리는 자신을 위해 코드를 작성하는 것이 아니라 다음에 이 코드를 보게 될 사라믈 위해 작성하는 것" 이라는 말을 자주 했음.

  - 이 책은 자바스크립트 코딩 컨벤션과 이에 대한 논의로 구성.

  - 가장 유명한 코딩 컨벤션 문서인 '자바 프로그래밍 언어 코드 컨벤션' 에서는 다음과 같은 이유로 코딩 컨벤션의 중요성을 언급


  * 소프트웨어를 사용하면서 드는 비용의 80%는 유지보수에 사용된다.

  * 소프트웨어 생명주기 동안 최초 개발자가 끝까지 유지보수하는 경우는 거의 없다.

  * 코딩 컨벤션은 소프트웨어의 가독성을 향상시켜, 개발자가 새로운 코드를 더 빠르고, 더 완전하게 이해할 수 있게 한다.

  * 소스 코드를 제품화 시키려면, 다른 제품들처럼 깔끔하고 잘 패키지화되는 것을 보장할 수 있어야 한다.


앞으로도 코더가 아니라 개발자가 되고 싶다.

좋은 개발자가 되기 위해서 이 책은 좋은 안내서가 될 수 있다고 생각한다.

이 책은 결국 좋은 결과물을 만들기 위한 책 이기 떄문이다.

Knockout의 대한 블로그 내용은 Knockout 홈페이지의 튜토리얼 기준으로 작성될 예정.

(outsider님(https://blog.outsider.ne.kr/)의 스프링 레퍼런스 번역 같은 느낌이랄까...)

Knockout 책도 존재하긴 하지만 Knockout 홈페이지의 Document보다 뛰어난 그 어떤 것도 없다고 생각한다.


Knockout을 접할때는 Document 먼저 펼처보기 보다는

Tutorials 먼저 시작해보는 것이 좋다.


Knockout Document URL:

http://knockoutjs.com/documentation/introduction.html


추가적으로 참고될 블로그는 knock Me out 이다.(작명 센스란..ㅋ)

해당 주소는 http://www.knockmeout.net/ 이다.


Knockout 공부를 하면서 자주 들락날락 해야할 사이트 중에 하나가 아닐까 싶다.

+ Recent posts