본문 바로가기

개발&새발/javascript

NHN Ent.의 자바스크립트 코딩컨벤션 그리고 하나더

NHN이 github도 운영하고 있었네요.

https://github.com/nhnent


"자바스크립트 개발 가이드"라는 이름의 피드가 있길래 들어가봤고 "코딩컨벤션" 내용이 눈에 들어왔는데 뻔한 내용이겠거니하고 들어갔다가 그 뻔한 내용을 다 읽어봤다.

https://github.com/nhnent/fe.javascript/wiki/%EC%BD%94%EB%94%A9-%EC%BB%A8%EB%B2%A4%EC%85%98


80%는 흔히 알고 잘 지켜지기도 하는 내용이고 10%정도는 안지켜도 그만. 하지만 나머지 10% 정도는 모르거나 잘 안지켜지는(손이 안나가는) 내용들이 있어 리스트업해본다.


자바스크립트의 개발툴은 notepad 부터 각종 IDE까지 너무나 다양한데다가 넘쳐나는 오픈소스 라이브러리들로 인해 제데로 그리고 편리하게 문법을 맞출 수 있고 인텔리센스 기능까지 완벽하게 갖추고 있지 못하다. 때문에 성능에 관련된 몇가지 룰(지역변수는 구현 초반에 선언해야 한다와 같은)보다 네이밍, 줄바꿈과 같은 편집상(?)의 룰이 매우 중요하다.(특히나 오픈소스 프로젝트에 참여한 경우 꽤나 많은 영문 메일을 받게 될꺼임)


우선 NHN Ent. 명명규칙을 보면 대부분 공감하지만 몇가지 이슈가 존재



명명규칙

  • 공백을 허용하지 않는다. - 이걸 굳이 언급해야 하나... -_-;;
  • 상수는 대문자와 '_'를 사용한다.
  • 생성자는 대문자 카멜표기법을 사용한다. - 소문자 카멜표기법을 사용하더라도 네이밍으로 이미 충분히 생성자임을 알수 있어야 할 듯
  • 함수, 변수는 소문자 카멜표기법을 사용한다.
    • 배열은 복수형 이름을 사용
    • 정규표현식은 'r'로 시작 - 이건 그냥 개취
    • 이벤트 핸들러는 'on'으로 시작
    • 반환 값이 불린인 함수는 'is'로 시작
    • private은 '_'로 시작 - scope chain의 구조에서 _의 구분이 inner annonimous function에 큰 혼란을 줄 수도 있음
    • 커스텀 객체의 프로퍼티 이름에도 동일 - 상동

응 작성하고 보니 대부분 까진 아닌듯... ㅡ,,ㅡ

하지만 줄바꿈과 문법은 대부분이 일치



줄바꿈

  • 변수 선언시 가독성이 떨어질때 변수당 줄바꿈 - 왠만하면 줄바꿈을 해야할 타이밍이 느낌같은 느낌으로 다가옴
  • 선언만 이뤄지는 경우 가급적 나열
  • 제어문 블럭 작성시 중괄호를 생략하지 않음 - 한방 소스는 없기 때문에 다시 이 부분을 건들때 중괄호 유무를 확인해야 한다는 건 꽤 괴로운 일이다.

  • 배역, 객체는 반드시 리터럴로 선언한다.
  • new Function()은 사용하지 않는다.
  • 구현 초반에 예외처리로 빠져나가는 로직이 있는 경우 가금적 해당 로직 이후 할당
  • 암묵적 캐스팅으로 인한 혼동을 막기 위해 완전항등연산자인 ===, !== 만 사용한다.
  • return문을 여러곳에 사용하지 않는다.

마지막으로 여기에 정확히(명확히 이해할만큼) 언급되어 있지는 않은 부분에 대한 개인적으로 가지고 있는 기준이 있다.

바로 문장종료시 사용하는 세미콜론(;)이다. 이건 기준이 되는 "문장"의 구분이 명확치 않기 때문인 것 같은데... 한번은 이 룰을 정해놓으니 if나 for문 블럭의 마지막에 ';'을 붙이는 개발자도 본적 있다.ㅎ

개인적인 기준은 
"제어문과 함수선언시에만 ';'을 사용하지 않는다"
이다.
여기서 애매한건 함수 선언시 인데 함수 선언의 방법이 두가지 이상 존재하기 때문이다.

함수 생성자를 이용한 할당 - ';'사용

 var doSomething = new Function() {};


함수 리터럴을 이용한 할당 - ';'사용

 var doSomething = function() {};


함수 표현식을 사용한 선언 - ';'사용안함

 function doSonething() {}


즉, 말 그데로 함수를 할당하는 경우는 그냥 할당문 인거다.

아마도 이 기준만으로도 바로 ';'의 사용여부를 판가름 할 수 있고 결국 'use strict'이 필요 없는 소스가 될 것 같다.



이정도가 공유된체로 팀개발이 이뤄진다면 꽤나 별 문제없이 일관된 팀개발 소스가 나오지 않을까 생각해본다. ^^