Convention

💻 코드 컨벤션

• 화살표 함수가 아닌 일반 함수를 사용한다.

• 파일 이름, 인터페이스, 타입, 컴포넌트 명 파스칼 케이스를 사용한다. ex) interface IHomeProps

• 컴포넌트 props 타입 선언 시 <컴포넌트명>Props 와 같은 형태로 작성한다.

• 디렉토리 명, 변수는 카멜 케이스를 사용한다. ex) let pinocoGame = "pinoco"

• 이벤트 핸들러 props에는 on 접두사를 붙이고, 값으로 넘길 때에는 handle 접두사를 붙인다.

• 함수 명은 동사 뒤에 명사가 오도록 조합하고 카멜 케이스로 작성한다.

• export 사용 시 named exports 방식을 사용한다.

• boolean 타입 변수 및 함수에는 접두사 is를 사용한다. (ex. isChecked)

• forEach, map, some, every 등의 고차 함수를 지향한다.

• const를 기본 값으로 하고, 값이 변경이 필요할 때만 let을 쓴다

• 상수 값들을 표현하는 변수는 enum 으로 선언하여 사용한다.

• type vs interface ⇒ interface로 통일하여 사용한다.

  • https://techblog.woowahan.com/9804/#toc-3

• interface 선언 시 이름 앞에 I를 붙인다.

• eslint와 prettier로 적용할 수 있는 것

  위에 언급하신 대부분의 코드 컨벤션 규칙은 ESLint와 Prettier에서 설정 가능하지만, 일부 규칙은 직접적인 설정이 불가능해 추가적인 규칙을 정의해야 할 수도 있습니다.

  ESLint 설정으로 가능한 규칙

  • 화살표 함수가 아닌 일반 함수 사용: @typescript-eslint/explicit-function-return-type 등의 룰로 함수 타입을 강제할 수 있지만, 일반 함수만 사용하도록 제한하는 규칙은 기본 제공되지 않습니다. 이를 해결하려면 코드 리뷰 단계에서 점검하거나 ESLint 커스텀 플러그인을 고려해야 합니다.
  • 이벤트 핸들러 및 함수 네이밍 (on 접두사, handle 접두사): ESLint 기본 플러그인에는 없지만, @typescript-eslint/naming-convention 룰을 이용해 함수 네이밍 컨벤션을 일부 적용할 수 있습니다.
  • 카멜 케이스와 파스칼 케이스 규칙: @typescript-eslint/naming-convention에서 인터페이스, 변수명, 타입 등의 네이밍을 설정할 수 있습니다.
  • Boolean 타입 변수 접두사 (is): @typescript-eslint/naming-convention 룰에서 적용 가능합니다.
  • 함수 이름 네이밍: @typescript-eslint/naming-convention을 통해 함수가 카멜 케이스로 작성되도록 규칙을 설정할 수 있습니다.
  • forEach, map 등의 고차 함수 지향: no-loops나 array-callback-return 등의 규칙을 사용하면 고차 함수 사용을 권장하고 일반 루프를 경고할 수 있습니다.
  • const 우선 사용: prefer-const 규칙으로 const 사용을 기본으로 하도록 설정할 수 있습니다.
  • Named exports 방식: import/no-default-export 룰로 기본 export를 제한하고 named exports를 권장할 수 있습니다.
  • 타입 선언 시 interface 사용: consistent-type-definitions 룰을 통해 interface 사용을 강제할 수 있습니다.

  ESLint와 Prettier 설정으로는 제한적인 규칙

  • <컴포넌트명>Props 형태의 props 타입 선언: 직접적으로 적용할 규칙은 없으므로, 이 부분은 코드 리뷰로 점검해야 합니다.
  • 상수 표현을 위한 enum 사용: ESLint에서는 이와 관련된 규칙을 기본으로 제공하지 않습니다. 직접적인 제한이 없으므로, 코드 리뷰나 TSLint를 활용해야 합니다.

  이를 기반으로 ESLint 설정 파일을 작성할 수 있으며, 일부 규칙은 추가적인 코드 검토 과정에서 보완해야 합니다. Prettier는 코드 포맷팅 규칙에 중점을 두고 있으므로 주로 들여쓰기, 공백, 라인 길이 등의 규칙을 설정할 수 있습니다.

🙏 커밋메시지 양식

<타입>: <제목>

ex) feat: 월과 일의 숫자를 두자리로 맞춰주는 기능

• feat : 기능 (새로운 기능)
• fix : 버그 (버그 수정)
• refactor : 리팩토링 (기능 변경 없이 코드 향상)
• style : 스타일 (포맷팅, 비즈니스 로직에 변경 없음)
• design: UI 퍼블리싱
• docs : 문서 (문서 추가, 수정, 삭제)
• test : 테스트 (테스트 코드 추가, 수정, 삭제: 비즈니스 로직에 변경 없음)
• chore : 설정 관련 변경사항 (빌드 스크립트 수정, package.json 등), 기타 등등

🎯 PR 컨벤션

## PR 제목 양식 : 커밋 메세지 형식
<-- ex) **[Fix] 제출버튼을 누르지 않으면 다음 라운드로 넘어가지 않는 버그 수정 -->

##** PR 라벨 : 타입, 중요도(important)

## assignee 본인 태그 필수

## 개요
<!---- 변경 사항 및 관련 이슈에 대해 간단하게 작성해주세요. 어떻게보다 무엇을 왜 수정했는지 설명해주세요. -->

<!---- Resolves: #(Isuue Number) -->

##  PR 유형
어떤 변경 사항이 있나요?

- [ ] 새로운 기능 추가
- [ ] 버그 수정
- [ ] CSS 등 사용자 UI 디자인 변경
- [ ] 코드에 영향을 주지 않는 변경사항(오타 수정, 탭 사이즈 변경, 변수명 변경)
- [ ] 코드 리팩토링
- [ ] 주석 추가 및 수정
- [ ] 문서 수정
- [ ] 테스트 추가, 테스트 리팩토링
- [ ] 빌드 부분 혹은 패키지 매니저 수정
- [ ] 파일 혹은 폴더명 수정
- [ ] 파일 혹은 폴더 삭제

## 작업 내용
<!-- 작업 사항에 대한 설명을 적어주세요 -->

## 스크린샷
<!-- 작업물에 대한 스크린샷을 첨부해주세요 -->

## 공유사항 to 리뷰어
<!-- 리뷰어가 중점적으로 봐주었으면 좋겠는 부분을 적어주세요 -->
<!-- 논의할 사항이 있다면 적어주세요 -->

## PR Checklist
PR이 다음 요구 사항을 충족하는지 확인하세요.

- [ ] 커밋 메시지 컨벤션에 맞게 작성했습니다.  Commit message convention 참고  (Ctrl + 클릭하세요.) 
- [ ] 변경 사항에 대한 테스트를 했습니다.(버그 수정/기능에 대한 테스트).

🎯 ISSUE 컨벤션

---
category: "✨ Feature Template"
about: 기능 추가 이슈 템플릿
title: ''
labels: ''
assignees: ''
---

## 어떤 기능인가요?

> 추가하려는 기능에 대해 간결하게 설명해주세요

## 작업 상세 내용

- [ ] TODO
- [ ] TODO
- [ ] TODO

## 참고할만한 자료(선택)

---
category: "\U0001F41B Bug Report Template"
about: 버그 리포트 이슈 템플릿
title: ''
labels: ''
assignees: ''
---

## 어떤 버그인가요?

> 어떤 버그인지 간결하게 설명해주세요

## 어떤 상황에서 발생한 버그인가요?

> (가능하면) Given-When-Then 형식으로 서술해주세요

## 예상 결과

> 예상했던 정상적인 결과가 어떤 것이었는지 설명해주세요

## 참고할만한 자료(선택)

---
category: "✅ Etc Template"
about: 기타 자유양식 템플릿
title: ''
labels: ''
assignees: ''
---

## (제목)
### (페이지)
- [ ] 구현내용1
- [ ] 구현내용2