[Coding convention] 코딩의 기본, 시대의 흐름으로 살펴본 헝가리안 표기법

얼마전 일입니다.

소스코드를 외부에 오픈하기 전, C코드를 위한 코딩 컨벤션을 정리하였습니다.

코딩 컨벤션은 비교적 의사소통이 잘되는 국내 개발자 뿐만 아니라-

상대적으로 소통이 적었던 해외 개발자에게도 전달되었습니다.

대부분의 규약들은 구렁이 담 넘어가듯 모두가 동의하였습니다.

하지만...

헝가리안 표기법 일부를 차용한 코딩 컨벤션에서,

해외 개발자의 문제제기를 시작으로 수많은 개발자들의 격렬한 논쟁이 시작되었습니다.

'70년대 감성을 갖고 있는 구닥다리 프로그래머'라든가

'읽기 힘든 코드를 끊임없이 양산해내는 두뇌파괴자'라는 식의 설전이 오고간 후,

우리는 헝가리안 표기법을 갖다버리기로 거국적으로 합의하였습니다.

그리고 아주 제한적인 경우에만 사용하기로 하였습니다.

목차격으로 마인드맵을 하나 붙입니다.

헝가리안 표기법이 혜성처럼 어느날 문득 시야에 나타난 것은 아닙니다.

타입시스템이 없는 BCPL(Before C Programming Language)과 같은 고대 언어에서는,

변수명으로 변수의 타입을 명시하여 사용하였습니다.

그러한 흐름이 자연스럽게 이어져,

70년대에 등장한 언어에서도 변수명에 타입이 함께 기입되었습니다.

설사 타입시스템이 있는 언어라 할지라도,

에디터나 컴파일러가 고도화되지 않은 환경에서는 변수명만으로 타입을 확정지을 수 있는 방식이 여러므로 유용하였습니다.

그 중 Smalltalk라는 객체지향언어에서는,

타입을 변수의 뒤에 붙여 기입하는 방식을 사용하였는데,

이는 유럽인들의 이름 뒤에 성이 오는 방식에서는 지극히 자연스러운 현상이었습니다.

타입은 일종의 가문과 같은 집단이라 볼 수 있으므로 변수고유의 이름과 타입이 순서대로 배치됩니다.

하지만, 유럽에서도 특이하게 성이 이름 앞에 오는 관습을 지닌 헝가리에서 온 청년-

Charles Simonyi이 타입을 앞에 붙이는 방식을 시전하게 됩니다.

80년대 마이크로소프트의 아키텍트가 된 Charles Simonyi은,

마이크로소프트에서 개발하는 앱의 기본 코딩컨벤션으로 자신이 제창한 헝가리안 표기법을 선정합니다.

컴파일러나 에디터가 아직은 조악했던 시절,

변수명만 가지고 타입을 확정지어 사용할 수 있는 방법은 여러므로 유용하였습니다.

코드작성자와 코드독해자가 동일한 헝가리안 표기법을 숙지하고 있다면,

변수의 타입을 해석하는데는 아무런 불편이 없습니다.

bBusy, chInitial, wCount, dwLength 등의 변수명만 보고도,

각각 bool, char, word, double word인 것을 파악할 수 있기에,

변수에 엉뚱한 값을 할당하는 실수를 예방할 수 있습니다.

이러한 점을 높이 사서,

마이크로소프트에서는 21세기 초반까지 헝가리안 표기법을 사용하고 지속적으로 권장하였습니다.

1999, "Hungarian notation... easier to write, and easier to read."^[각주:1]

그 결과,

헝가리안 표기법은 유행처럼 전세계 프로그래머들에게 퍼져나갔습니다.

학부 프로그래밍 강좌에서도 시험문제로 단골출제되었고,

전문프로그래머 사이에서는 지극히 당연한 교양처럼 여겨졌습니다.

80~90년대 격동의 학번을 경험한 중장년층 프로그래머들에게는 헝가리가 일종의 마음의 성지였죠.

하지만, 컴파일러는 더욱 똑똑해져서 컴파일 중에 수많은 warnings으로 개발자의 실수를 찾아주고,

에디터는 변수에 마우스 포인터를 갖다대는 것만으로 변수의 타입을 친절하게 팝업으로 보여주게 됩니다.

이러한 환경의 변화로 헝가리안 표기법에 대한 사람들의 인식도 바뀌어 갑니다.

2005, "Systems Hungarian had far less useful... But there’s still a tremendous amount of value to Apps Hungarian"^[각주:2]

2008, "Do not use Hungarian notation"^[각주:3]

2009, "vUsing adjHungarian nNotation vMakes nReading nCode adjDifficult."^[각주:4]

         

"변수명에 굳이 타입을 prefix로 붙여야만 할까요?"

2005년, <조엘 온 소프트웨어>로 유명세를 타고 있는 조엘 스폴스키는 자신의 블로그에서 포문을 열었습니다.

헝가리안 표기법의 창시자인 Charles Simonyi의 논문을 언급하며,

본래의 헝가리안 표기법은 단순히 타입을 반복하여 적는 것이 아니라고 주장했습니다.

단순히 타입을 반복하는 표기법을 시스템 헝가리안 표기법이라고 말하며,

그 대신 필수적으로 명시해야할 변수의 의미를 prefix로 표기하는 앱 헝가리안 표기법을 사용하라고 권장하였습니다.

이를테면,

count에 사용하는 변수엔 'n',

index에 사용하는 변수엔 'i',

두 변수값의 차이를 가지는 변수엔 difference의 약자인 'd',

database의 각 row에 해당하는 변수엔 row의 약자인 'rw',

code injection 등의 공격을 받을 수 있는 스트링 변수에는 unsafe의 약자인 'us'를 붙입니다.

앱 헝가리안 표기법은 통일된 prefix가 없습니다.

(혹은 모두가 합의하여 정리된 prefix가 없습니다.)

한 쪽에서는 치밀한 분석과 고민으로 prefix를 썼지만,

다른 쪽에서는 공유되지 않은 semantics로 해석하기 힘든 변수가 될 수 있습니다.

이에 따라 2008년에는 헝가리안 표기법을 널리 퍼뜨렸던 마이크로 소프트가,

.NET Framework 4.5 General coding conventions 에서 헝가리안 표기법을 사용하지 말라고 합니다.

그리고 온라인에서는 서서히 헝가리안 표기법을 조롱하며 웃는 분위기가 조성됩니다.

"vUsing adjHungarian nNotation vMakes nReading nCode adjDifficult."

위의 문장은 제법 유명세를 탔는데,

각 단어 앞에 헝가리안 표기법에 따라 동사, 부사, 명사 등을 나타내는 prefix를 붙였습니다.

읽기... 쉬운가요?

이런 상황에서 해외 개발자에게 헝가리안 표기법을 사용하자고 제안했으니,

'두뇌파괴자(brain breaker)'라는 소리를 들을만 했죠.

하지만, 그 와중에도 살아남아 고이 간직하게 된 헝가리안 표기법이 있습니다.

바로 변수의 scope를 나타내는 prefix.

local 변수에는 'l_'을,

argument 변수에는 'a_'를,

member 변수에는 'm_'을,

global 변수에는 'g_'를,

클래스 스태틱 변수에는 's_'를,

함수 스태틱 변수에는 'c_'를 붙입니다.

로컬변수와 아규먼트변수에 사용하는 prefix는 거의 사용하지 않지만,

나머지 것들은 아직도 코드에 살아남아 그 명맥을 유지하고 있습니다.

코딩 컨벤션이 뭐라고 조선시대에 벌인 예송논쟁처럼 수많은 개발자들이 핏대를 높였지만,

시대와 환경에 따라 유연하게 대처하며 사용하면 됩니다.

끝_

1. Microsoft : Hungarian Notation, https://msdn.microsoft.com/en-us/library/aa260976(VS.60).aspx [본문으로]
2. Joel on Software : "Making Wrong Code Look Wrong", http://www.joelonsoftware.com/articles/Wrong.html [본문으로]
3. Microsoft : "General Naming Conventions". https://msdn.microsoft.com/en-us/library/ms229045.aspx [본문으로]
4. stackoverflow : "Why shouldn't I use “Hungarian Notation”?", http://stackoverflow.com/questions/111933/why-shouldnt-i-use-hungarian-notation [본문으로]