목차
1 개요
컴퓨터 프로그래밍에서 변수 및 함수의 인자 이름 앞에 데이터 타입을 명시하는 코딩 규칙이다.
찰스 시모니(Charles Simonyi) 가 마이크로소프트의 개발 책임자로 있을 때 제안했으며, 80년대 당시에는 IDE라는게 다들 부실했기 때문에 물론 볼랜드의 Turbo C 같은 예외도 있었지만 이 규칙이 엄청난 센세이션을 불러 일으켰다. 하지만 지금은 MS도 공식 가이드라인에서 사용하지 말 것을 권고[1]하고 있다.
헝가리안 표기법이라는 명칭은 제안자인 찰스 시모니가 헝가리인이라서 붙은 것이다.
2 적용하기
아래 표만 잘 기억하면 된다. 참 쉽죠?
물론 이렇게 정해야 한다는 명확한 룰 자체가 없으므로, 사용자나 이를 설명한 사이트에 따라 조금씩 다를 수는 있다.
2.1 Systems Notation
데이터 타입을 명시하는 방식으로, 널리 쓰이는 방식이다.
2.1.1 공통
접두어 | 데이터 타입 |
b | byte, boolean |
n | int, short |
i | int, short (주로 인덱스로 사용) |
c | int, short (주로 크기로 사용) |
l | long |
f | float |
d, db | double |
ld | long double |
w | word |
dw | double word |
qw | quad word |
ch | char |
sz | NULL로 끝나는 문자열 |
str | C++ 문자열 |
arr | 배열 (문자열 제외): 다른 접두어와 조합 가능 |
p | 포인터 (16비트, 32비트): 다른 접두어와 조합 가능 |
lp | 포인터 (64비트): 다른 접두어와 조합 가능 |
psz | NULL로 끝나는 문자열을 가리키는 포인터 (16비트, 32비트) |
lpsz | NULL로 끝나는 문자열을 가리키는 포인터 (64비트) |
fn | 함수 타입 |
pfn | 함수 포인터 (16비트, 32비트) |
lpfn | 함수 포인터 (64비트) |
2.1.2 OOP
접두어 | 데이터 타입 |
g_ | 네임스페이스의 글로별 변수 |
m_ | 클래스의 멤버 변수 |
s_ | 클래스의 static 변수 |
c_ | 함수의 static 변수 |
다른 타입 접두어 앞에 붙인다. (예: m_lpszName - 클래스 멤버 변수인 문자열 포인터)
이 접두어들은 당연히 private 멤버에 사용하는 것이다. 절대 public으로 오픈하지 말 것.
2.1.3 Windows API
접두어 | 데이터 타입 |
h | 리소스 핸들 (HWND를 제외한 모든 HANDLE 타입) |
hwnd | Windows 핸들 |
Windows API 문서를 보면 wParam과 lParam이 지겹게 등장하는데, 접두어대로 wParam은 word나 dword 기반, lParam은 int나 long 기반이다.
2.2 Apps Notation
데이터 타입이 아닌, 데이터의 논리적 상태를 명시하는 방식이다.
3 장점
- 데이터 타입을 변수명에서 바로 추정할 수 있다.
- IDE가 없을 때 작업하는 경우 (특히 vi나 emacs로 터미널에서 작업할 때) 여러모로 유리해진다.
- 같은 의미를 가지는 서로 다른 타입의 변수가 있을 때 이름 충돌을 방지할 수 있다.
4 단점
- 아이러니하게도, 코드를 단번에 파악하기 힘들어진다.
- 변수나 함수 인자의 이름을 기억하기가 힘들다.
- 데이터 타입이 바뀌면 변수 또는 함수 인자의 이름을 바꿔야 한다. 리팩토링을 지원하는 IDE가 없으면 지옥도가 펼쳐질 것이다.
- C(프로그래밍 언어)/C++일 경우 언어 명세에서 데이터 타입의 크기를 강제하지 않은 바람에 시스템 아키텍처에 따라 데이터 타입의 크기가 다르다는 무시 못할 문제가 있다.[2] 예를 들어 w는 16비트일까? 32비트일까? 64비트일까?
묵념 - 같은 의미를 가지는 서로 다른 타입의 변수가 있을 때 이것들을 왜 선언했는지를 잊어버렸다면 혼돈! 파괴! 망가!가 연출된다.
주석은 이럴 때 다는 것이다.
5 몰락
디스플레이 화면이 커지면서 한 눈에 볼 수 있는 코드의 양이 많아지고, IDE가 눈부시게 발전하면서 마우스 커서만 올리면 해당 변수의 데이터 타입이 뙇!하고 나오는 덕에 헝가리안 표기법은 바로 구식으로 변하고 말았다. 단, IDE를 써먹을 수 없는 환경에서 일하는 사람들은 이거 안쓰면 대략 망하므로, 명맥은 유지하고 있다...는데 이쪽도 싫어하는 사람 많다(..) 심지어 완전히 동적 타입언어인 Python에서도 헝가리안 표기법 없이 잘만 코딩하는 사람이 많다는게 불필요성을 증명한다 대신 C++에서 클래스 멤버 변수인 경우에 이름 뒤에 _를 붙이는 정도로 간소화 해서 쓰는 경우는 있다.
데이터의 논리적인 상태를 나타내는 Apps Notation은 지금도 간간히 쓰이고 있다.
6 관련 문서
- ↑ [4] 내용 자체는 .net 프레임웍에 적용되는 문서이긴 하지만 새로 만드는 SDK의 API들은 헝가리안 표기법에서 탈피하고 있다.
- ↑ 2010년대는 소프트웨어가 AMD x86-64로 이관하는 과정이 진행 중이기 충분히 생길 수 있는 문제이다.