명명 규칙

명명 규칙(영어: naming convention)은 컴퓨터 프로그래밍 및 정보 시스템에서 변수, 자료형, 함수, 클래스, 파일, 데이터베이스 객체 등 각종 엔티티(entity)를 나타내는 식별자(identifier)에 사용할 문자 시퀀스를 선택하는 규칙의 집합이다. 명명 규칙은 소스 코드, 문서, 시스템 간 인터페이스 등 다양한 정보 자산에서 일관성과 가독성을 확보하기 위해 사용된다.

개요

명명 규칙은 프로그래머가 어떤 문자 시퀀스든 자유롭게 선택할 수 있는 상황과 달리, 일정한 기준을 두어 이름을 통일함으로써 다음과 같은 목적을 달성하고자 한다.

• 소스 코드를 읽고 이해하는 데 필요한 노력을 줄인다.
• 코드 리뷰가 구문 및 명명 표준보다 더 중요한 문제에 집중할 수 있도록 한다.
• 코드 품질 검토 도구가 구문 및 스타일 이외의 핵심 문제에 초점을 맞출 수 있도록 한다.
• 식별자가 사용되는 용도에 대한 추가 정보(메타데이터)를 제공한다.
• 개발 팀 내에서 일관성을 증진하고 기대치를 공식화한다.
• 자동화된 리팩터링(refactoring) 및 검색·바꾸기 도구의 효과적인 사용을 가능하게 한다.
• 잠재적 모호성을 줄이고 명확성을 높인다.
• 여러 조직의 작업 산출물이 결합될 때 발생할 수 있는 명명 충돌(naming collision)을 방지한다.

어원

'명명 규칙'이라는 용어는 한자어 '命名'(이름 명, 이름 낼 명)과 '規則'(규칙 규, 법칙 칙)의 합성어로, '이름을 짓는 규칙'을 의미한다. 영어 'naming convention'에서 비롯된 개념으로, 20세기 중반 컴퓨터 프로그래밍 언어의 발전과 함께 체계화되기 시작하였다.

주요 요소

식별자 길이

식별자의 길이는 모든 명명 규칙의 기본 요소이다. 일부 규칙은 고정된 길이 제한을 두기도 하지만, 대부분의 현대 규칙은 지침(guideline) 형태로 제시된다. 짧은 식별자는 입력이 편리하다는 장점이 있지만, 자동 검색 및 바꾸기 도구에서 구별이 어려울 수 있다. 긴 식별자는 의미 전달력이 높지만 시각적 혼란을 초래할 수 있다.

대소문자 및 문자 사용

일부 명명 규칙은 대문자 또는 소문자의 사용에 제한을 두거나, 특정 해석을 부여한다. 또한 알파벳, 숫자, 영숫자(Alphanumeric) 문자의 사용 가능 여부와 순서를 지정하기도 한다.

여러 단어 식별자

대부분의 프로그래밍 언어는 식별자에 공백을 허용하지 않으므로, 여러 단어로 구성된 이름을 처리하기 위한 다양한 방식이 개발되었다. 주요 방식은 다음과 같다.

주요 명명 표기법

카멜 표기법 (Camel Case)

단어의 첫 글자를 대문자로 표기하여 단어 경계를 나타내는 방식이다. 첫 글자를 소문자로 시작하는 lowerCamelCase(또는 dromedaryCase)와 첫 글자도 대문자로 시작하는 UpperCamelCase(또는 PascalCase)로 구분된다. 자바(Java), C#, 자바스크립트(JavaScript) 등에서 널리 사용된다.

스네이크 표기법 (Snake Case)

단어 사이를 밑줄(_)로 구분하는 방식이다. C 계열 언어, 파이썬(Python), 루비(Ruby) 등에서 주로 사용된다. 모든 문자를 대문자로 표기하는 SCREAMING_SNAKE_CASE는 상수(constant)나 매크로(macro)의 이름에 흔히 사용된다.

케밥 표기법 (Kebab Case)

단어 사이를 붙임표(-)로 구분하는 방식이다. 리스프(Lisp), 코볼(COBOL), CSS, 유닉스(Unix) 명령어 및 패키지 이름에서 사용된다. 대부분의 프로그래밍 언어는 식별자에 붙임표를 허용하지 않으므로(뺄셈 연산자와의 충돌), 주로 파일명이나 설정값 등에 사용된다.

헝가리안 표기법 (Hungarian Notation)

변수 이름에 접두사를 붙여 해당 변수의 자료형이나 용도를 표시하는 방식이다. 마이크로소프트(Microsoft)의 프로그래머 찰스 시모니(Charles Simonyi)에 의해 개발되었으며, '시스템 헝가리안'(자료형 인코딩)과 '앱 헝가리안'(목적 인코딩)으로 나뉜다. 현재는 대부분의 최신 언어 및 프레임워크에서 권장되지 않는다.

언어별 명명 규칙

Java

• 클래스: UpperCamelCase (예: Raster, ImageSprite)
• 메서드: lowerCamelCase (예: run(), getBackground())
• 변수: lowerCamelCase (예: myWidth)
• 상수: SCREAMING_SNAKE_CASE (예: MAX_PARTICIPANTS)
• 패키지: 소문자와 마침표 사용 (예: com.example.myapp)

Python

• 클래스: UpperCamelCase
• 함수 및 변수: snake_case
• 상수: CAPITALIZED_WITH_UNDERSCORES
• 비공개(private) 의도: 밑줄 접두사 (예: _internal)
• 특수 메서드(dunder): 이중 밑줄 접두사 및 접미사 (예: __init__)

C / C++

• 표준 라이브러리: snake_case (예: isalnum, out_of_range)
• 매크로: SCREAMING_SNAKE_CASE (예: NULL, EINVAL)
• 구현 예약: 이중 밑줄 또는 밑줄+대문자로 시작 (사용자 사용 금지)

C#

• 대부분의 식별자: PascalCase
• 매개변수 및 지역 변수: camelCase
• 인터페이스: 'I' 접두사 + PascalCase (예: IEnumerable)
• 비공개 필드: 종종 _camelCase 사용 (관례적)

JavaScript

• 생성자 함수 및 클래스: UpperCamelCase
• 함수 및 변수: lowerCamelCase
• 상수: SCREAMING_SNAKE_CASE 또는 lowerCamelCase

Go

• 여러 단어: MixedCaps 또는 mixedCaps 사용 (밑줄 비권장)
• 첫 글자 대문자: 외부 패키지에 내보내기(export)
• 첫 글자 소문자: 현재 패키지 내에서만 사용 가능

Rust

• 타입, 구조체, 트레이트, enum: UpperCamelCase
• 상수/정적 변수: SCREAMING_SNAKE_CASE
• 변수, 함수, 구조체 멤버: snake_case

SQL / 데이터베이스

• 데이터베이스 및 테이블: snake_case 또는 PascalCase
• 컬럼: snake_case
• 명확한 규칙은 공식적으로 정해져 있지 않으며, 조직별로 내부 규칙을 정하여 사용한다.

과제 및 논란

명명 규칙의 선택과 그 시행 정도는 종종 논란이 되는 주제이다. 각각의 규칙이 최고라고 주장하는 다양한 입장이 존재하며, 이는 구어적으로 '종교적 논쟁'(religious issue)이라고 불리기도 한다. 명명 규칙이 내부적으로 일관성이 없거나, 임의적이거나, 기억하기 어려울 경우 오히려 생산성을 저하시킬 수 있다. 또한 조직 내에서 잘 정의된 규칙이 마련되어 있더라도 일관성 있게 준수되지 않으면 혼란을 초래할 수 있다.

같이 보기

• 코딩 스타일
• 식별자
• 이름공간 (Namespace)
• 리팩터링