| Table of Contents |
|---|
개요
세상에는 다양한 editor 와 IDE 가 있고 여러 개의 수많은 문자 encoding 이 방식이 존재합니다.
어떤 OS 는 줄 바꿈을 의미하는 개행 문자를 LF(line feed) 만 쓰고 어떤 OS 는 CR + LF(Carriage Return + Line Feed) 를 쓰기도 합니다.
코딩은 대부분의 코딩 작업은 다수간의 협업이기 때문에 사용하는 도구는 취향대로 써도 되지만 작성하는 코드는 source code는 표준을 만들고 이를 준수해야 합니다.
예로 표준이 없고 누구는 개행을 LF 로 쓰고 누구는 CR + LF 로 쓴다면 한 쪽에서 커밋한 소스를 다른 쪽에서 내려받는다면 CR + LF 문제로 인해 변경한 게 없어도 모두 변경해야 한다고 나올수 소스 코드의 변경이 없어도 변경되었다고 표시될수 있습니다.
누구는 들여쓰기를 tab 을 tab 으로 쓰고 누구는 space 4칸, 다른 이는 space 2칸을 쓴다면 다른 이의 작업을 내려받으면 내 PC 에서는 늘 늘 변경되었다고 표시되고 커밋 대상으로 나올겁니다나오게 됩니다.
과거에는 이런 문제를 해결하기 위해 특정 에디터를 강제하거나 IDE 를 포함해서 개발 환경을 배포하는 등 여러 가지 불편함과 비효율이 많았습니다.
EditorConfig 는 이렇게 환경(Editor, OS, encoding 으로 인해 소스 코드의 fIle encoding)에 따라 코딩 스타일의 일관성이 깨지는 문제를 해결하기 위한 표준으로 표준으로 character encoding, 개행 처리 방법, 들여쓰기 방법(tab인지 space 인지) 등을 정의하고 , 사용하는 있으므로 Editorconfig 를 지원하는 에디터를 사용한다면 프로젝트 참여자들의 일관된 코딩 스타일을 유지할 수 있습니다.
사용
프로젝트 root 에 .editorconfig 파일을 만들고 프로젝트 참여자들간의 일관성 유지를 위해 이 파일을 버전 관리에 추가해 주면 됩니다.
| Code Block |
|---|
# EditorConfig is awesome: https://EditorConfig.org
# top-most EditorConfig file
root = true
# Unix-style newlines with a newline ending every file
[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true
indent_style = space
indent_size = 4
trim_trailing_whitespace = true
[*.md]
trim_trailing_whitespace = false
[*.{yml,yaml}]
indent_size = 2
# Matches multiple files with brace expansion notation
# Set default charset
[*.{js,py}]
charset = utf-8
# 4 space indentation
[*.py]
indent_style = space
indent_size = 4
# Tab indentation (no size specified)
[Makefile]
indent_style = tab
# Matches the exact files either package.json or .travis.yml
[{package.json,.travis.yml}]
indent_style = space
indent_size = 2 |