Vision
home
CLASS101 Vision
home
◼️

Frontend Code Style Guide

CLASS101 FE 코드 컨벤션 가이드 입니다. 컨벤션을 추가할 땐 예시를 꼭 적어주세요.

TypeScript Style Guide

Variables

file-scope 상수는 UPPER_CASE로 적습니다.
그 외에는 모두 camelCase로 적습니다.
맨 앞에 _ 가 붙은 변수는 사용하지 않는 변수입니다.
Boolean 타입의 변수는 is, has, can과 같은 접두사를 붙입니다.
__ 접두사는 자동으로 생성되는 파일에만 붙습니다.

Types & Enums

Type에 Interface를 사용하지 않습니다.
Type, Enum은 PascalCase로 적습니다.
Enum의 값(Value)도 PascalCase 로 적습니다.
함수 타입은 <이름>: <타입>으로 적습니다.
타입 변환은 명시적으로 합니다.
any 타입을 사용하지 않습니다. 가급적 제네릭 타입을, 그것도 안되면 unknown 타입을 사용해야 합니다.
제네릭을 사용할 때 T, U, V 같이 한 문자가 아닌 명시적인 이름을 사용합니다.

Functions

함수 이름은 동사로 시작합니다.
페이지 이동 메서드(함수) 이름은 다음과 같이 정의합니다.

Control Statements

if 문 작성시 반드시 중괄호를 사용합니다.

React/JSX Style Guide

React 컴포넌트는 반드시 함수형으로 작성합니다.

Event Handler

Component Prop로 넘기는 이벤트 핸들러에는 on 접두사를 붙입니다.
이벤트 핸들러 이름은 Noun first 로 네이밍합니다.

Props Naming

Props 타입 정의 이름은 컴포넌트이름+Props 로 합니다.
Hook의 prop type 네이밍은 Use<...>Props로 합니다.
Boolean타입의 props는 선언적으로 작성합니다.

File Naming

React Component를 정의한 파일은 PascalCase 로 적습니다.
React Component를 포함하고 있지 않다면 .ts로 파일을 정의합니다.

Query & Mutation

서버에서 정의한 Query name + On + 컴포넌트 이름 으로 정의합니다.
서버에서 정의한 Mutation 이름 + On + 컴포넌트 이름으로 정의합니다.
Fragment 이름은 Fragment 이름 + On + 컴포넌트 이름 으로 정의합니다.
다른 컴포넌트의 제너레이트 파일에 접근할땐 index 파일로 접근합니다.
Deprecated

Context API 사용 규칙

최대한 사용하지 않는 것이 원칙입니다.
Context에서는 상태만 가지고 있고, Context를 사용하는 쪽에서 로직을 정의합니다.
상태를 공유할 때는 Render Prop을 사용하여 공유합니다.

역할 분리

Feature 라이브러리에서의 Component - Hook 분리 규칙
Hook에서는 View component의 상태는 알되, UI 구성은 몰라야 합니다.
View Component에서는 hook에서 넘어온 두개 이상의 값을 조합하지 않습니다.
View Component에서는 return 키워드를 사용하지 않습니다.

인라인 함수

인라인 함수는 가능하면 사용하지 않습니다.

Component Definition

index.ts 파일에는 컴포넌트를 정의하지 않습니다.
한 폴더에는 하나의 컴포넌트만 정의합니다.
한 파일에는 하나의 컴포넌트만 정의합니다.

Component Layout

컴포넌트를 구성하는 가장 바깥요소는 여백(margin, padding) 을 가질 수 없습니다.

Feature/Shell

Feature, UI안에서는 window 객체에 접근하지 않습니다.
로직을 담당하는 hook 파일의 리턴값을 중첩해서 리턴하지 않습니다.
컴포넌트를 작성할때 라이브러리는 ‘react’만 import 가능합니다.

Comments

되도록 주석 없이 코드로 표현하는 것이 좋으나, 다음과 같은 상황에서는 주석을 사용합니다.
주석은 다음 중 하나 이상의 목적을 가져야 합니다. - 다음에 누군가가 해당 코드를 작업할 때 염두에 두어야 할 부분을 지키기 쉽게 합니다. - 누군가가 코드 상의 버그나 이상한 동작을 디버깅 할 때, 코드를 이해하고 고치는데 도움을 줍니다. - 코드에 대한 설계 수준의 정보를 간략하게 설명하여 해결해야 하는 문제가 무엇인지 파악하기 쉽게 합니다.
TODOFIXME 주석은 지나치게 쌓이지 않게 적절히 관리해야 합니다.
문제를 일으킬 수 있지만 당장은 고치지 않을 때는 FIXME(assignee): 코멘트를 적습니다.
기능이나 최적화, 리팩토링 면에서 미래에 하면 좋을 부분을 표시할 때는 TODO(assignee): 주석을 적습니다.
코드로 표현이 어려운 소프트웨어 스펙의 애매한 부분을 강조해서 표시할 때는 NOTE:코멘트를 적습니다.
저희와 함께 코드리뷰 문화를 만들어나가는건 어떠실까요? 관심 있으신 분들은 아래 채용공고 참고해주세요:)