[C++ 스타일 2편] 네이밍 컨벤션: 변수명, 함수명, 클래스명, 그리고 언더스코어 vs. 카멜케이스

C++ 코드에서 이름 짓기는 매우 중요한 요소입니다. 변수, 함수, 클래스, 네임스페이스, 매크로, 열거형 등 다양한 요소에 이름을 부여할 때, 일정한 규칙을 따르면 코드를 읽는 이가 의도를 더 쉽게 파악할 수 있습니다. 하지만 네이밍 컨벤션에 대한 스타일 가이드들은 저마다 다른 권장사항을 내놓습니다. 어떤 곳은 함수명을 CamelCase로, 어떤 곳은 snake_case로 쓰라고 하고, 또 다른 곳은 클래스 앞에 C를 붙이는 구시대적 관례를 아직도 유지하기도 합니다.

이 글에서는 구글 C++ 스타일 가이드, LLVM 스타일 가이드, 모질라 스타일 가이드 등 다양한 스타일 가이드에서 권장하는 네이밍 컨벤션을 비교하고, 각 스타일의 장단점을 분석합니다. 또한 팀이나 프로젝트 상황에 따라 어떤 네이밍 컨벤션을 선택하면 좋을지 제안합니다.

다양한 스타일 가이드의 예

• 구글 C++ 스타일 가이드:
  • 함수 이름: MixedCase (대문자로 시작, 단어 구분 시 대문자)
  • 변수 이름: snake_case (소문자, 단어 구분 시 언더스코어)
  • 클래스 이름: PascalCase (대문자로 시작, 단어 구분 시 대문자)
  • 클래스 멤버 변수: 뒤에 언더스코어 붙이기 권장(example: my_member_variable_)
• LLVM 스타일 가이드:
  • 함수, 변수, 클래스 이름: 일반적으로 MixedCase 또는 camelCase를 권장,
    세부사항은 프로젝트별로 다를 수 있으나, LLVM은 함수명 등에서 대문자로 시작하는 CamelCase를 즐겨 사용.
  • 네임스페이스, 타입명: PascalCase에 가까운 형태 사용.
• 모질라 스타일 가이드:
  • 함수, 변수 모두 snake_case 권장.
  • 클래스 이름: PascalCase를 사용하지만 접두사 ns를 붙이는 등 특정 프로젝트 관례도 존재.

이외에도 각 회사나 오픈소스 프로젝트는 자체적인 규칙을 정할 때, 명확한 일관성과 역사적 이유, 언어적 합의를 근거로 스타일을 정하곤 합니다.

장점 및 단점 분석

CamelCase, PascalCase, snake_case 비교

CamelCase (myVariableName)

• 장점: 각 단어 경계를 대문자로 표시해 읽기 쉽고, 다양한 언어에서 흔히 쓰여 익숙함.
• 단점: 연속된 대문자나 특정 약어 처리(HTMLParser vs HtmlParser) 시 혼란.

PascalCase (MyClassName)

• 장점: 클래스나 타입명에 자주 사용, 타입임을 직관적으로 전달 가능.
• 단점: 함수명, 변수명에 일관 적용 시 단어 경계 인식은 쉽지만 코드 전체가 대문자로 시작하는 경우 혼재하면 헷갈릴 수 있음.

snake_case (my_variable_name)

• 장점: 소문자와 언더스코어만 사용하므로 단순하고 일관적. C, Python 전통과 유사해 C++ 이전 언어 습관에 자연스러움.
• 단점: 단어 길이가 길어질수록 언더스코어가 많아지고, CamelCase보다 길게 느껴질 수 있음.

멤버 변수 접미사(underscore), 접두사(m_), g_ 패턴 등

일부 스타일은 클래스 멤버 변수에 _를 접미사로 붙여 로컬 변수나 파라미터와 구분합니다(my_member_variable_). 다른 스타일은 헝가리안 표기법(접두사에 m_나 g_ 등)을 사용해 멤버나 전역 변수를 표기하기도 합니다.

• 장점: 이름만 보고 범위나 스코프를 파악하기 쉬움.
• 단점: 시대에 뒤떨어진 관례로 보일 수 있고, IDE 지원이 우수한 환경에서는 굳이 이런 접두/접미사를 사용할 필요가 적어짐.

대문자/소문자 구분, 약어 처리

약어(HTML, URL, HTTP)를 포함한 이름 처리도 스타일 차이가 큽니다.

• 어떤 가이드는 약어를 전부 대문자로 유지(HTTPRequest)
• 다른 가이드는 첫 글자만 대문자로(HttpRequest)
  이 부분은 프로젝트 내에서 합의가 필요합니다.

어떤 경우 어떤 선택을 할까?

• 규모가 큰 오픈소스 프로젝트: 일관성과 명확성, 그리고 기여자들의 친숙도를 고려해 보편적인 컨벤션(함수: lowerCamelCase, 클래스: PascalCase, 변수: snake_case) 조합을 택하기도 합니다.
• 사내 프로젝트, 모두 한 언어 스타일에 익숙: 팀원 대부분이 Python 경험이 많다면 snake_case로 통일, Java/Kotlin에 익숙하다면 CamelCase 스타일을 택하는 것도 합리적입니다.
• IDE/툴 사용 환경: 현대 IDE는 변수 타입, 선언 위치, 스코프를 쉽게 보여주므로 멤버 변수 접두/접미사 없이도 큰 혼란 없이 코딩이 가능합니다. 이 경우 좀 더 심플한 규칙을 택해도 무방합니다.

실제 예제 코드 비교

// 구글 스타일 예:
class MyClass {
 public:
  MyClass() : my_member_variable_(0) {}
  void SetValue(int new_value) { my_member_variable_ = new_value; }
 private:
  int my_member_variable_;
};

// 모질라 스타일 예(가상의):
class MyClass {
public:
    MyClass() : my_member_variable(0) {}
    void set_value(int new_value) { my_member_variable = new_value; }
private:
    int my_member_variable;
};

위 예제에서 구글 스타일은 멤버 변수에 언더스코어를 붙여 명확히 구분, 모질라 스타일은 snake_case로 모두 통일했습니다.

마무리

네이밍 컨벤션은 정해진 정답이 없습니다. 중요한 것은 팀 합의, 문서화, 일관성, 그리고 자동화된 체크(예: clang-tidy, cpplint)를 통한 일관 유지입니다. 프로젝트 요구사항과 팀원들의 배경을 고려해 합리적인 규칙을 정하고, 이를 모두가 따르는 것이 핵심입니다.

다음 편에서는 헤더 파일 구조, #include 순서, 전방 선언, 헤더 가드 vs. #pragma once 등 파일 구조와 의존성 관리 관련 스타일 이슈를 다루어 보겠습니다.