[FE] 코드 컨벤션 - woowacourse-teams/2026-gachi-gacha GitHub Wiki

1. Prettier

항목 기준
세미콜론 사용
따옴표 작은따옴표
들여쓰기 스페이스 2칸
탭 문자 사용하지 않음

import 순서

다음 순서로 import문을 정렬합니다.

  1. Node.js 내장 모듈
  2. React 및 React DOM
  3. 외부 패키지
  4. @/ 절대경로
  5. 상대경로

예시:

import path from 'node:path';

import { useEffect } from 'react';
import { http } from 'msw';

import { Button } from '@/components/Button';

import { handlers } from './handlers';

각 그룹 안에서는 대소문자를 구분하지 않고 알파벳 오름차순으로 정렬합니다.

2. 네이밍

  • 폴더/파일명 규칙 (PascalCase vs camelCase vs kebab-case)
    • 컴포넌트 파일만 PascalCase, 나머지는 camelCase, 폴더는 camelCase
  • 컴포넌트 파일과 훅 파일의 구분
  • boolean 변수 접두사 (is, has, can)
  • 상수 (UPPER_SNAKE_CASE)

3. 폴더 구조

  • 공통 컴포넌트와 도메인 컴포넌트 분리 기준
    • 일단 만들고 공통으로 3번 겹치면 분리한다.

4. 컴포넌트 작성

  • 함수 선언문 vs 화살표 함수

      1. 주요 비즈니스 로직은 함수 선언문
      1. 배열 메서드의 콜백은 화살표 함수
      1. 객체 메서드는 메서드 축약 문법
    // 컴포넌트 → 함수 선언문
function UserProfile() {
  // ...
}

// 이벤트 핸들러 → 화살표 함수
const handleClick = () => {
  // ...
};

// 배열 콜백 → 화살표 함수
users.map((user) => {
  // ...
});

  • export default vs named export ⇒ 추후 리뷰 시 논의

  • Props 타입 정의 위치와 네이밍 (ButtonProps)

    • 기준: 그 파일 내부에서만 사용한다
    • 위의 기준을 바탕으로 Props

  • 컴포넌트 분리 기준 (재사용성,도메인)

  • 조건부 렌더링 방식 (삼항 or early return)

5. TypeScript

  • type vs interface 사용 기준
    • type 변하지 않는
    • interface 변할 수 있는
  • any, unknown 금지
  • 타입 단언(as) 허용 범위
    • 최대한 사용하지 않는 방향으로 하지만 그로인해 너무 코드가 방대해 진다면 as 사용
  • 타입 파일 위치 (컴포넌트 옆 vs types/ 폴더)
    • types/ 폴더로(api로 들어오는 정보들)

6. 스타일링

  • styled vs css prop 중 무엇을 기본으로 ⇒ styled-component
  • 스타일 코드 위치 (.styles.ts 분리)
  • 디자인 토큰/테마 정의 방식과 사용 규칙
    • #FF0000 베이스
  • 반응형 브레이크포인트 정의
    • 모바일 360px, 패드 960px, 1024이상이 pc뷰? pc뷰에다가 모바일처럼 구현 예정 ⇒ 적당한 모바일 규격을 찾아서 통일

7. 상태 관리

  • 전역 상태로 올리는 기준 ⇒ 불필요한 렌더링이 일어날 때
  • 서버 상태와 클라이언트 상태 분리 여부 ⇒ 시퀀스 다이어그램 그리면서 추후 생각
  • 커스텀 훅으로 추출하는 기준 ⇒ 피어리뷰에서 확인

8. Git / 협업

  • 브랜치 전략과 브랜치 네이밍 (feat/cart-coupon) ⇒ 팀 규칙
  • 커밋 메시지 컨벤션 (Conventional Commits 등) ⇒ 팀 규칙(Angular)
  • PR 템플릿, 제목 형식
  • 리뷰 규칙 (approve 몇 개? 리뷰 응답 기한? DM 알림?)!!!!
  • 머지 방식 (squash / rebase / merge commit)!!!!!!

9. 테스트 & 문서

  • 테스트 파일 위치와 네이밍 (.test.tsx)
  • 무엇을 테스트할지 기준
    • Jest를 통한 도메인 기능 테스트
    • 스토리북을 통한 개별 컴포넌트
    • MSW를 통한 백엔드 통신 파이프라인
  • Storybook 스토리 작성 대상과 형식
    • 개별 컴포넌트 확인 및 페이지 완성 전 개발용
  • MSW 사용여부 > 백엔드 개발 보고 유동적으로?
    • API 통신 관련 테스트 전담

10. 기타

  • 매직 넘버/문자열 상수화 규칙
  • 주석을 언제 쓸지 > 안쓰는 위주로
  • console.log 잔여 금지
  • 에러 처리 방식 통일 > 에러 뜰 때 프론트끼리 함께 이야기하기

11. 브라우저 별 대응

  • 추후 조사 필요