Convention

컨벤션 룰

🤗 Naming

파일명

• 파일명은 기본적으로 PascalCase로 작성한다.
• style은 컴포넌트 파일과 함께 작성한다.(emotion)

변수명

• 변수명은 기본적으로 camelCase를 사용한다.
• 가능한 명사를 사용한다.
• 복수의 경우 복수형 명사를 사용한다.
• boolean 형을 갖는 변수는 앞에 is를 붙인다.

함수명

• 함수명은 기본적으로 camelCase를 사용한다.
• 가능한 동사를 사용한다.
• 함수명을 축약하지 않는다.
• boolean형을 return하는 함수는 앞에 check를 붙인다.

스타일

• 공통 스타일 속성, 변수는 메인 Stylesheet에 정의
• 이후 각 컴포넌트마다 해당하는 스타일을 emotion/styled-components 로 정의
• 스토리북을 통해 컴포넌트 구현 및 테스트 진행

이벤트 핸들러 네이밍

• props는 on~
• 함수이름은 handle~

😝 Type Conventions

https://react-typescript-cheatsheet.netlify.app/docs/basic/getting-started/basic_type_example#more-advice

• API, library 등의 타입을 정의할 때는 추후 확장에 용이하도록 interface를 사용한다.
• Props, State 등의 타입을 정의할 때는 일관성과 제한적이기 때문에 type을 사용한다.

🙄 Issue Conventions

• Issue 내용은 Todo-List 형식으로 작성한다.
• Issue 단위는 기능 단위로 작성한다.
• Issue 명
  • feat/Issue 명
  • fix/Issue 명

👊 Commit Message Conventions

• 커밋 시 아래 규칙을 참고해 메세지를 작성하자, 영어로 작성할 필요는 없다.
• issue-number는 Github의 issue를 발급하고, 생성된 번호를 사용한다.

✨ feat: 파일, 폴더, 새로운 기능 추가
🐛 fix: 버그 수정
💄 style: 코드 스타일 변경 + UI 변경
📝 docs: 문서 생성, 추가, 수정 README.md
♻️ refactor: 코드 리팩토링
💩 chore: 수정 (JSON 데이터 포맷 변경 / css 변경 등)

😾 Github branching

• main : 배포 (버전)
• feature/{issue-number} : 기능 구현 branch
• fix/{issue-number} : 버그 수정 branch
• feature -> (배포) main

👊 PR Title Conventions

• feature/{issue-number} {desc}

👶 Code

• VS Code의 eslint와 prettier extention을 활용한다.
• 버그가 있으면 커밋 할 수 없다.
• 한 메서드에 오직 한 단계의 들여쓰기(두 단계까진 봐줌)를 하기 위해 노력한다. (3단계 안 들어가도록?)
• else 예약어는 권장하지 않음
• 상수는 두 파일 이상 사용할 경우 별도의 파일로 분리해서 작성한다.