예전에는 우스개로 보고 넘긴 이 그래프에, 이제는 항목 마다 십분 아니 백분 공감하는 바이다. 개중에서도 변수명 짓기는 여전히 나에게 많은 고통을 주고있다. 그러나 변수명이라는 것은 단순히 명명의 의미를 넘어서, 동료와의 협업과 커뮤니케이션에 많은 영향을 주는 요소이다.
내가 생각하는 변수명짓기의 의미는 크게 두가지로, 다음과 같다.
1. 기능과 의미의 내포
변수명, 함수명, 파일명 그리고 폴더명은, 그 이름만 보아도 어떤 기능과 의미를 가지고 있는지 직관적으로 파악할 수 있어야 의미를 파악하기 위한리소스의 낭비를 줄일 수 있다. 이는 동료개발자 뿐만아니라 근 미래에 코드를 다시 열어볼 자기 자신을 위한 배려이기도 하다. 변수명을 적확하게 짓는것은 조급하고 정신없이 코딩을 치기 바쁠 때에는 번거롭게 느껴지겠지만, 결과적으로는 기둥이 튼튼한 집을 짓는(코드를 짜는) 초석이 된다. semantic 한 것은 변수명 짓기에서도 매우 유익하다.
2. Conflict와 error 예방
아직까지 정확한 이유를 밝혀내지 못했지만, 간혹 파일명의 대소문자가 동료와 다를 경우 merge 할때 덮어씌워지거나 제대로 파일이 들어오지 않는 현상을 경험했다. git이 대,소문자를 구별하지 못하는 것인지.. 알 수 없다. component 를 import 할때도 컴포넌트명과 파일명이 통일 되지 않거나, 중간에 바뀌면 계속 생기는 error 를 해치워줘야한다.(ex. landingpage, landingPage, LandingPage, Landingpage가 난무하는 총체적 난국. . .)vscode 가 자동으로 변환해 주기도 하는데, 아닐때도 있어서 문제다. 게다가 엉망진창 내 코드를 pull받은 동료도 일일이 수정해야하는 번거로운 과정을 거쳐야한다.
이와같은 이유로 jake님과 나는 front-end naming convention을 정하기로 했다.
- 기본적으로 lowerCamelCase 를 사용한다. (변수명 & 함수명)
- 약어는 모두 대문자 혹은 모두 소문자로 사용한다 (ex. http)
- export되는 파일 내의 모든 상수는 모두 대문자로 표기한다.
- 줄임말을 사용하지 않는다.(ex. del⇒ delete)
- 파일과 폴더명은 default export와 반드시 일치시킨다.
- 컴포넌트 명은 대문자로 시작하며, 파스칼케이스를 사용한다. (ex. LandingPage)
- 폴더명은 모두 소문자를 사용한다.
- 타입스크립트(*.ts) 확장자 ⇒ 케밥 케이스를 사용한다. (ex. react-app-env.d.ts)
- 이미지 파일 ⇒ 케밥 케이스를 사용한다.
(ex. picnic-original.jpg )
참고: 자바스크립트 스타일 가이드
<느낀점>
컨벤션을 정하고 나니 보다 쾌적한 개발 환경속에서 코딩에 집중할 수 있게 되었다.
- 서로 완전히 합의한 가이드를 아무런 의심없이 따르기만 하면 되니 불필요한 시간낭비나 논쟁이 줄었고, 개인적인 실수가 줄었다.
- 사람인지라 늘 컨벤션을 기억하기 어려운데, 문서를 참고해서 작업하니 편리하다.
- 부작용으로 영어로된 단어나 구를 볼 때마다 컨벤션대로 뜯어고치고 싶은 찝찝함을 얻었다.
