사실상 프로그래밍에서, 명명규칙은 종교적 신념에 가깝다. 어느것이 좋고 나쁘고는 개인적 신념에 따라 갈리기 때문에 '좋은' 명명규칙을 말하기란 불가능에 가깝다. 그럼에도 불구하고 (칼 포퍼의 철학을 따르자면) '나쁜' 명명규칙을 구분할 방법은 존재하고, 그 대표적 사례가 헝가리안 노테이션이다. 아니, 정확히는 '변질된 헝가리안 노테이션'이 나쁜 명명규칙의 대표적 사례이다.
조엘에 따르면, 시모니가 만든 최초의 헝가리안 노테이션 규칙은 변수의 타입이 아닌, 변수의 '종류', 즉 쓰임새에 따라 접두어를 붙이는 방식이었는데, (행을 나타내는 변수는 rw, 열을 나타내는 변수는 col등의 접두어) 이에 대해선 유용하다는 것에는 별 이의가 없는듯 하다. 하지만 이렇게 유용했던 헝가리안 노테이션이 변수의 타입을 나타내는 접두어를 붙이는 것으로 변질되면서부터 모든 문제가 시작됐다. 구분하기 위해 원래의 규칙을 App Hungrian, 뒤의 것을 System Hungarian이라고 하자.
시스템 헝가리안의 문제는, 변수의 접두어가 특별한 정보를 전혀 담고 있지 못하다는 것에 있다.
void* p;
LPVOID lpvP; // (1)
여기서 (1)의 접두어 lpv는 그저 '타입이 없는 포인터'라는, 컴파일러가 이미 알고 있는 정보를 중복해서 적어 놓은 것 뿐이다. 선언부의 중복은 말할 것도 없지만, 이것을 실제로 쓰는 쪽에서는 저런 정보가 유용하지 않느냐는 주장도 있는데, 실제로 쓰는 쪽에서도 실제 타입을 인간이 알아야만 제대로 된 코드를 작성할 수 있는 경우는 드물다.
void* q1 = p; // (2)
void* q2 = lpvP; // (3)
현대적인 컴파일러에서 경고나 에러 없이 훌륭히 컴파일된 코드라면, (2)의 코드만으로도 p의 타입이 '타입이 없는 포인터'라는 점을 언제나 알 수 있다. 구태여 (3) 처럼 손가락 아프게 써 봐야 이미 알고 있는 정보를 중복해서 기재한 것 밖에는 안된다. 이는 함수호출시에도 마찬가지이다.
그리고 언제나 그렇지만, 중복은 혼란을 가져온다.
포인터 p가 void*였다가, 어느 순간 메모리 위치 계산을 위해 1바이트 형에 대한 포인터로 바꿔야 할 때가 올 수 있다. 이럴 때 시스템 헝가리안은 대 혼란을 몰고 온다.
시스템 헝가리안을 쓴다고 가정해 보자. (2)의 코드에서 LPVOID로 되어 있는 것을 LPBYTE로 바꾸면, 다음과 같이 된다.
LPBYTE lpvP;
void* q2 = lpvP; // (4)
여기서 (4)의 코드는 언제나 훌륭하게 컴파일 되지만, 변수명은 잘못된 정보를 나타내고 있다. 이제 더이상 lpvP는 void*타입이 아니라, char*타입인 것이다. 따라서 시스템 헝가리안은 변수타입을 바꿀 때 변수명도 함께 바꿔야 한다. 규칙 안에 정보가 중복되도록 마련된 규칙이기 때문이다.
그리고 무엇보다, 시스템 헝가리안은 타이핑하기에 불편하다.lpcsz, lplpdw, lplpci, lpctsz.. 이런 접두어를 치다가 손가락이 꼬일 지경이다.
wchar_t* name;
LPTCHAR lpszName;
이 경우에 단순 비교만 하더라도, 헝가리안 노테이션은 변수이름이 2배로 길어진다. 프로그래밍에서는 row, col, len 같은 간단한 이름의 변수를 절대적으로 많이 쓰는데, 일일이 시스템 헝가리안을 지켜가며 명명하기엔 상당히 번거롭다. 번거로우면 잘 안지키게 되며, 잘 안지키는 규칙은 쓸모가 없거나, 나쁜 규칙이다. 자세한 건 위에 있는 조엘의 링크를 따라가보라.
난 개인적으로 명명규칙은 다음과 같은 조건만 만족하면 된다고 생각한다.
1) 특별한 정보를 전달하지 못하는 접두어/접미어가 없을 것.
2) 멤버변수와 로컬변수를 구분할 수 있을 것.
3) 처음보는 사람도 알 수 있도록 과도한 축약표현을 하지 말 것.
이 이외의 조건은 명명규칙에 있어서는 불필요한 군더더기 제약일 뿐이라고 생각한다.
