개발 스타일 가이드

에디터/IDE 스타일링 표준화

로컬로 파일을 저장하기 전에 특정한 스타일링 표준을 자동으로 적용하기 위해 EditorConfig를 사용합니다. 일부 편집기 및 IDE는 .editorconfig 설정을 자동으로 지원합니다.

에디터 또는 IDE가 .editorconfig를 자동으로 지원하지 않는 경우, 플러그인이 있는지 여부를 조사해보기를 건의합니다. 예를 들어, vim용 플러그인이 있습니다.

Pre-push 정적 분석은 Lefthook로 실행

Lefthook는 커밋하거나 푸시하기 전에 사용자 정의 로직을 실행할 수 있는 Git 후크 관리자입니다. GitLab에는 Lefthook 구성(lefthook.yml)이 함께 제공되지만 설치해야 합니다.

우리는 Lefthook보다 먼저 Overcommit을 사용했었기 때문에, 먼저 overcommit --uninstall로 삭제할 수 있습니다.

Lefthook를 여러 가지 방법으로 설치할 수 있습니다. 전역으로 설치하는 것이 아니고(예를 들어 Homebrew나 패키지 관리자를 통해) GitLab 프로젝트에서만 사용하려면 루비 젬을 설치할 수 있습니다: 

bundle install

Lefthook 관리 Git 후크를 설치하세요: 

# 전역으로 설치된 경우
lefthook install
# 루비 젬을 통해 설치된 경우
bundle exec lefthook install

Lefthook의 pre-push Git 후크를 실행하여 Lefthook가 작동하는지 테스트하세요: 

# 전역으로 설치된 경우
lefthook run pre-push
# 루비 젬을 통해 설치된 경우
bundle exec lefthook run pre-push

이 명령은 Lefthook 버전과 실행 가능한 명령의 디렉터리을 반환해야 합니다.

Lefthook는 다음과 같이 구성됩니다:

사용자 브랜치에서 변경된 파일에 대해 모든 린터를 자동으로 실행하는 사용자 지정 lefthook 대상이 있습니다. 

# 전역으로 설치된 경우
lefthook run auto-fix
# 루비 젬을 통해 설치된 경우
bundle exec lefthook run auto-fix

Lefthook를 임시로 비활성화하려면 LEFTHOOK 환경 변수를 0으로 설정하세요. 예를 들어: 

LEFTHOOK=0 git push ...

pre-push Git 후크를 실행하려면 다음을 실행하세요: 

bundle exec lefthook run pre-push

자세한 정보는 Lefthook 문서를 참조하세요.

푸시할 때 태그별로 일부 검사를 건너뛰려면 LEFTHOOK_EXCLUDE 환경 변수를 설정하세요. 예를 들어: 

LEFTHOOK_EXCLUDE=frontend,documentation git push ...

대안으로 다음 구조를 가진 lefthook-local.yml을 생성할 수 있습니다: 

pre-push:
  exclude_tags:
    - frontend
    - documentation

자세한 정보는 Lefthook 문서 구성를 참조하세요.

푸시할 때 이름에 따라 검사를 건너뛰거나 활성화하려면 해당 훅을 위한 lefthook-local.yml 섹션에 skip: true 또는 skip: false를 추가하세요. 예를 들어, locale/gitlab.pot에서 발생하는 문제를 감지하기 위해 gettext 검사를 활성화하려면: 

pre-push:
  commands:
    gettext:
      skip: false

자세한 정보는 Lefthook 문서 검사 건너뛰기 섹션을 참조하세요.

데이터베이스 마이그레이션

전용 데이터베이스 마이그레이션 스타일 가이드를 참조하세요.

JavaScript

전용 JS 스타일 가이드를 참조하세요.

SCSS

전용 SCSS 스타일 가이드를 참조하세요.

Ruby

전용 루비 스타일 가이드를 참조하세요.

Go

전용 Go 표준 및 스타일 가이드를 참조하세요.

셸 명령어 (루비)

GitLab 코드베이스에서 셸 명령어에 대한 가이드라인을 참조하세요.

셸 스크립팅

셸 스크립팅 표준 및 스타일 가이드를 참조하세요.

Markdown

우리는 Ciro Santilli의 Markdown 스타일 가이드를 따릅니다.

문서

전용 문서 스타일 가이드를 참조하세요.

좋은 실천 지침

좋은 실천 예제는 코드 작성의 권장 방법을 보여주며 피해야 하는 실천 예제와 비교합니다. 이러한 예제는 나쁨 또는 좋음으로 표시됩니다. GitLab 개발 가이드에서는 사례를 제시할 때 먼저 나쁜 것 다음에 좋은 것 전략을 따르는 것이 권장됩니다. 먼저 나쁜 실천 방법을 제시하고(종종 여전히 작동하는 코드인) 어떻게 더 나아졌는지(좋은 예제)를 보여줍니다.

예제를 제공할 때 다음 지침을 고려하세요:

  • 먼저 나쁜 예제를 제시한 후 좋은 예제를 제시하세요.
  • 하나의 나쁜 경우와 하나의 좋은 경우만 제공하는 경우 동일한 코드 블록을 사용하세요.
  • 여러 개의 나쁜 경우 또는 하나의 좋은 경우가 제공되는 경우 각각을 위한 별도의 코드 블록을 사용하세요. 다수의 예제가 제시될 때 명확한 구분은 독자가 바로 좋은 부분으로 이동할 수 있도록 도와줍니다. 왜 어떤 것이 안 좋은 실천인지 설명(예: 주석 또는 리소스 링크)하는 것을 고려하세요.
  • 더 나은 사례와 최상의 사례는 좋은 사례의 코드 블록의 일부로 고려될 수 있습니다. 동일한 코드 블록에서 각각을 설명하는 주석(예: # 더 나은 및 # 최상의)을 앞에 붙입니다.

나쁜 후에 좋은 방법을 보여주는 접근은 GitLab 개발 가이드에서는 허용되지만 사용자 설명서에는 사용하지 마세요. 사용자 설명서에는 할 것과 하지 마세요를 사용하세요. 예시는 Pajamas Design System을 참조하세요.

Python

전용 Python 개발 가이드라인을 참조하세요.

Misc

코드는 미국 영어로 작성되어야 합니다.