공백
이전에는 숏코드라는 말이 대세로 떠오른 적이 있었던 것 같다.
공백 또한 node이기때문에 빌드 속도를 높이기 위해 주석이나 공백을 최대한 쓰지 말아야 한다는 의미였던 듯.
그러나 지금은 개발중/빌드/배포 등의 과정이 많이 분리되었다.
여러 툴들이 개발이 되면서부턴데, 웹팩같은 툴을 써서 트리쉐이킹을 통해 최대한 코드를 컴팩트하게 줄이고 쓰지 않는 코드들을 정리한다.
개발 중에는 협업이 중요하고, 다른 사람의 코드를 읽고 파악이 빠르게 되어야 하기 때문에 '공백'을 통해 가독성을 확보하고 '주석'을 달아 이해를 돕는다.
그래서 공백도 코드 작성의 일부 라는 것이다.
그렇다고 공백을 남발하면 오히려 가독성, 집중력이 떨어지게 될 것이다.
공백은 어디에 두어야 할까
- 선언
- 로직, 문
- 반환
여기서 각 코드의 역할에 따라 묶거나 떨어트리는 것을 볼 수 있다.
어느정도 협업을 하다보면 '어디쯤에 무엇이 있겠거니' 하는 예상을 하게 된다.
어떻게 보면 정리를 잘 하라는 이야기로도 들린다.
같은 결에서, 파일이나 폴더의 구조에서도 어디쯤에 어떤 컴포넌트, 어떤 훅, 어떤 타입이 있겠거니 하는 예상을 하고 찾아보게 된다.
폴더를 책상 서랍이라고 생각하고 어떤 이름의 폴더(서랍)에 어떤 파일이 들어가야할지 고민해보고 컨벤션에 따라, 또 개발자들이 으례 하는 관습에 따라 정리를 하는 습관을 들이는 것이 좋겠다.
style guide
프로젝트를 진행하면서 ide 설정에 따라 다른 사람이 작성한 코드를 열어 봤을때, 포매팅이 되는 때가 있다.
필자는 보통 들여쓰기 간격을 2로 두고 tab도 잘 쓰기 때문에 tab간격도 2로 설정해두었다.
거기에 코드 마지막엔 꼭 ;를 붙이고, 맨 마지막 줄은 공백으로 설정했다.
다른사람이 indent를 4로 두고 쓰는 등 나와 굉장히 다른 포맷으로 코드를 작성한다면, 실질적인 코드에는 아무런 변화가 없는데도 쓸데없이(?) 커밋을 날리게 되기도 한다.
그래서 처음 프로젝트를 진행할 때 꼭 통일을 하고 진행하는 것이 필요하다.
이때 의식적으로 컨벤션을 따르기 위해 노력하는 것도 좋지만 웬만하면 ide 설정이나 eslint, prettier 등 툴의 도움을 받는 것이 여러모로 생산적이고 이롭다.
indent depth: depth 줄이기
- 조기반환
- callback => Promise => Async Await
- 고차함수
- 함수를 나누고 추상화
- 메서드 체이닝
style guide
네이밍 컨벤션을 포함. 협업에 도움을 주기 위함
- 이해하기 위한 시간 절약
- 코드 품질 향상
- 일관성
- 가독성
- 유지보수 용이
style guide example
몇 유명한 스타일가이드
