REAME.md? ReadMe.md? read_me.md? read-me.md?
프로그래밍 세계에서는 변수명의 대소문자(case)를 표기하는 여러 관행이 존재한다. 이에 대해서는 워낙 많은 글이 널려 있으니 여기서 구태여 반복할 필요는 없겠다. 가장 중요한 공통점은 중간에 공백이 들어가면 안된다는 것 정도일 것이다. 참고로 '_'를 흔히 국내에서 under bar라고 부르는데, 영어권의 공식 명칭은 underscore이다.
대표 표기 스타일
| 스타일 | 예시 | 특징 / 용도 |
|---|---|---|
| camelCase | fileName |
첫 단어는 소문자, 이후 단어의 첫 글자만 대문자 |
| PascalCase | FileName |
모든 단어의 첫 글자를 대문자(클래스/타입 이름에 자주 사용) |
| snake_case | file_name |
단어 사이를 언더스코어(_)로 구분(Python에서 흔함) |
| kebab-case | file-name |
단어 사이를 하이픈(-)으로 구분(URL/HTML/CSS에서 흔함) |
| SCREAMING_SNAKE_CASE | FILE_NAME |
대문자 + 언더스코어(상수/환경변수에 자주 사용) |
낙타의 혹(camelCase), 땅바닥에 붙어서 기어가는 뱀(snake_case), 꼬챙이에 각종 재료의 가운데를 꽂아서 만든 케밥(kebap-case)을 떠올리면 왜 이런 스타일 이름이 붙는지 쉽게 이해할 수 있을 것이다.
이 스타일을 파일명에나 폴더(디렉토리)명에 그대로 적용해도 별 상관은 없다. 그러나 소스 파일에 따라서는 약간 다른 관례가 존재한다. 예를 들어 웹에서는 kebab-case를 많이 쓰고, 파이썬에서는 sanke_case(.py)가 거의 표준이다. OS에 따라서는 대소문자를 구분하기도 하고 그렇지 않기도 한다. GitHub는 리눅스나 윈도우 양측에서 접근하는 경우가 많으니 파일과 디렉토리 이름에 신경을 좀 써야 한다. 강제되는 규칙이 있는 것은 아니지만 대체로 다음을 권장한다.
- 디렉토리 이름: kebab-case(1순위), snake_case(2순위)
- 파일 이름: snake_case(C/C++/Arduino에서 강력 권장), kebab-case 또는 camelCase(JavaScript/웹)
AudioDriver.cpp와 audiodriver.cpp는 리눅스에서는 다른 파일이지만 윈도우에서는 같은 것으로 인식한다. 따라서 파일명은 전부 소문자를 쓰는 것을 강력히 권장한다. Windows의 국문 표준 표기는 '윈도'이다. 그러나 이렇게 쓰려면 영 어색하다...
파이썬 파일명은 특별히 주의해야 한다. 다른 스크립트에서 모듈로 임포트할 소스에는 하이픈('-')을 사용할 경우 에러를 낸다. 예를 들여 midi-parser.py라는 파일이 별도로 존재하는데 이를 다른 스크립트에서 'import midi-parser'로 읽어들이면 에러가 발생한다. 따라서 import_parser.py로 이름을 붙여야 한다.
그러면 GitHub에서 문서 파일명은 어떻게 해야 하는가? 코드 파일과는 또 약간 다른 관례가 있다고 한다. 가장 흔한 것은 kebab-case이고 그 다음으로는 snake_case이다. camelCase나 PascalCase는 권장하지 않는다. 그러나 매우 중요한 예외가 있으니 그것은 바로 루트에 존재하는 표준 문서다. README.md, LICENSE, CHANGELOG.md 등은 전부 대문자로 고정한다.
정리해 보자. 이 글을 작성하는데 ChatGPT의 도움을 많이 받았다.
🎯 선택 가이드
-
📚 문서 공개/오픈소스 강조 → kebab-case
🧩 임베디드/툴체인 중심 → snake_case
-
👤 개인 프로젝트 → 일관성만 유지하면 OK
🔷 한 줄 결론
GitHub 문서 파일명:
일반 문서 →
kebab-case⭐ 또는snake_case루트 표준 문서 → README.md 등 대문자 고정
camelCase / PascalCase → 문서에는 비권장
댓글 없음:
댓글 쓰기