C++ 코드 스타일에서 가장 먼저 부딪히는 문제 중 하나가 바로 들여쓰기(Indentation)입니다. 개발자는 최소한의 수평 정렬을 통해 코드 계층 구조를 표현하는데, 이때 스페이스(space)와 탭(tab) 중 무엇을 사용할지, 기본 들여쓰기 폭은 얼마로 할지, 그리고 라인 길이는 어느 정도로 제한할지를 결정해야 합니다.
본 글에서는 대표적인 스타일 가이드(구글 C++ 스타일 가이드, LLVM 스타일 가이드, 모질라 스타일 가이드 등)가 들여쓰기 관련 규칙을 어떻게 정의하는지 살펴봅니다. 또한 스페이스 대비 탭 사용의 장단점, 긴 라인을 어떻게 줄여나갈지에 대한 조언, 팀 내에서 일관성을 강제하는 방법 등을 다룰 것입니다.
다양한 스타일 가이드의 예
- 구글 C++ 스타일 가이드: 스페이스 사용 권장(2칸 들여쓰기), 탭 금지. 라인 길이는 80자 내외 권장.
- LLVM 스타일 가이드: 스페이스 사용(기본 2칸), 라인 길이 80자 권장. 엄격히 강요하진 않음.
- 모질라 스타일 가이드: 스페이스 4칸 들여쓰기 권장, 라인 길이는 80자 권장.
- 기타 프로젝트들: 예를 들어 Chromium 프로젝트는 구글 스타일을 기반으로 하며, 다른 오픈소스 프로젝트들은 탭 사용이나 라인 길이를 100자 이상 허용하는 경우도 있음.
구글 스타일은 스페이스를 통해 어디서나 동일한 시각적 결과를 보장하고, 코드 리뷰나 협업 도구에서 균일한 레이아웃을 보장한다고 설명합니다. 반면 탭을 선호하는 프로젝트에서는 탭으로 개인별 환경에 맞춘 가독성을 조정할 수 있다고 주장합니다.
장점 및 단점 분석
스페이스 사용 시 장점
- 모든 개발 환경에서 동일한 시각적 결과를 보장
- 코드 리뷰, 웹 인터페이스에서 균일한 레이아웃 유지 용이
스페이스 사용 시 단점
- 사용자별 가독성 조정이 어렵다(탭 폭 조절 불가)
- 파일 크기가 커질 수 있으나, 일반적으로 무시할 수준
탭 사용 시 장점
- 탭 폭을 사용자 환경에 맞게 조절 가능
- 한 번에 논리적 블록 이동이 편리할 수 있음
탭 사용 시 단점
- 서로 다른 편집기 설정 시 레이아웃 불일치 가능성
- 코드 리뷰 도구 등에서 의도치 않은 정렬 깨짐 발생
라인 길이 제한 관련
- 80자 제한: 터미널 환경, 좁은 화면에서 편리, 코드 리뷰에 유리
- 100자 이상 허용: 현대 디스플레이 환경을 고려한 여유로운 스타일, 긴 이름이나 템플릿 표현에 유리
어떤 경우 어떤 선택을 할까?
- 대규모 오픈소스 프로젝트: 다양한 기여자가 있으며, 각자 다른 환경에서 작업하므로 스페이스 기반, 80자 내외 규칙이 관리하기 유리.
- 사내 프로젝트, 동일한 개발 환경: 팀원이 모두 같은 IDE나 에디터 설정을 공유한다면 탭 사용도 큰 문제 없음.
- 현대적 디스플레이 활용: 100자 이상의 라인 길이를 허용해서 가독성을 해치지 않고, 긴 식별자나 템플릿 사용을 쉽게 할 수도 있음.
결국 팀 합의와 일관성이 핵심입니다. 어떤 방식을 택하든지 팀 전체가 같은 규칙을 준수하도록 하고, CI 파이프라인이나 린터를 통해 이를 자동화하면 관리가 편해집니다.
실제 예제 코드 비교
// 스페이스(2칸), 80자 제한 예:
int main() {
int value = 42;
// 짧은 줄 유지
}
// 탭 사용, 4칸 렌더링 가정 예:
int main() {
int value = 42; // 에디터에 따라 표시 폭 다를 수 있음
}
단순한 예제이지만, 대규모 코드에서는 이런 차이가 누적되어 코드 전체의 일관성에 큰 영향을 줍니다.
마무리
들여쓰기와 공백 규칙은 사소한 문제처럼 보이지만 코드 일관성과 협업 효율성을 좌우하는 중요한 요소입니다. 스페이스 vs. 탭, 라인 길이 규칙 등은 정답이 없으며, 프로젝트 특성, 팀원 선호, 개발 환경에 따라 최선책이 달라집니다. 중요한 것은 일관성과 합의, 그리고 이를 보조하는 자동화된 검증 체계입니다.
다음 편에서는 네이밍 컨벤션, 헤더 파일 구조 등 또 다른 코드 스타일 이슈를 유사한 방식으로 분석하고, 다양한 스타일 선택지와 그 특징을 살펴보겠습니다.
'개발 이야기 > C++' 카테고리의 다른 글
[C++ 스타일 3편] 헤더 파일 구조: #include 순서, 전방 선언, 헤더 가드 vs. #pragma once (0) | 2024.12.15 |
---|---|
[C++ 스타일 2편] 네이밍 컨벤션: 변수명, 함수명, 클래스명, 그리고 언더스코어 vs. 카멜케이스 (1) | 2024.12.15 |
[모던 C++ #11] 모던 C++으로 가는 여정의 마침표: 이제 어떤 길을 갈까? (0) | 2024.12.14 |
[모던 C++ #10] 직접 구현한 알고리즘 대신 C++20 Ranges와 병렬 알고리즘으로! (0) | 2024.12.14 |
[모던 C++ #9] 직접 스레드 관리에서 std::jthread와 코루틴으로! (0) | 2024.12.14 |