오늘 ‘조엘 온 소프트웨어를 넘어서’를 보았습니다. 많은 내용이 ‘조엘 온 소프트웨어’의 재탕이라 실망한 부분도 있었지만, 새로운 내용도 몇 있었고, 꽤 가치있는 내용입니다.

지난 포스트에서 헝가리안 표기법을 무시했었는데, 이 책을 읽고 나니 다시 생각해야겠다는 생각이 들었습니다. 사실 이 책을 구매한 이유의 중 하나가 이 챕터를 보기 위해서였습니다.

내용을 요악하면 헝가리안 표기법의 원래 목적은 변수의 타입을 구분하기 위한 것이 아니라, 변수의 종류를 구분하기 위한 것이었다는 겁니다. 이것이 MS 내에 존재하는 2류 프로그래머들에게 제대로 전달되지 않아 지금 오명을 뒤집어쓰고 있다는 것이죠.

헝가리안 표기법을 처음 봤을 때 세상에 뭐 이런 멍청한 표기법이 있나 하는 생각이 들 정도였습니다. 잘못 알려진 헝가리안 표기법은 컴파일러가 완벽하게 검사해주는 기본 타입을 중복해서 표기합니다.

// Prefix 'ui' means 'unsigned int'.
unsigned int uiVar1 = 0;
unsigned int uiVar2 = 0;

완벽한 낭비인데다가 가독성을 향상시키지도 못합니다. 원래는 이런 것입니다.

// Prefix 'x' means 'x axis'.
// Prefix 'y' means 'y axis'.
unsigned int xVar1 = 0;
unsigned int yVar1 = 0;

같은 타입의 변수라 해도 다른 영역에서 쓰인다면 이들은 구분되어야 하고, 시각적으로도 잘 인지되어야 한다는 것입니다. 조엘은 헝가리안 표기법을 매우 좋아하는데 헝가리안 표기법에도 문제는 있습니다. 그것은 프리픽스를 약어로 사용한다는 것입니다.

// Prefix 'uwc' means 'UI Window Coordinate'.
function func1(int uwcVar1);

약어는 시간이 지나면 작성자도 못알아보는 암호가 되고, 결국 위와 같이 내용을 중복해서 설명하는 주석을 달아야 합니다. 이것보다는 단어 전체를 사용하는 애플 방식이 더 낫습니다.

(void)func1: (int)userWindowCoordinateVar1;

너무 깁니다. 그래서 타이핑이 힘들죠. 하지만 읽는 것은 더 쉽습니다. 작성 후 몇 달이 지났다고 생각하면 더 생각할 필요도 없죠. 애플의 길다란 네이밍 방식에 대해 ‘너무 길다’라고 불평하는 사람은 코드 유지관리를 해본적이 없는 사람입니다. 작성할 때 몇 글자만 더 타이핑하면 두고두고 보기 쉬운 코드를 만들 수 있습니다. 게다가 Xcode, Eclipse, VS.NET 등 대부분의 메이저 IDE는 강력한 이름 완성 기능을 제공합니다. 그래서 실제로 타이핑하는 양은 별 차이가 없습니다. 이름 자동 완성 기능이 없는 편집기를 쓰고 계시다면 할 말이 없네요. 저는 기억력이 모자라서 그런 편집기로는 코딩 못합니다.

헝가리안 표기법의 가치

중요한 것은 컨셉입니다. 변수명을 일종의 수식어로 데코레이트하는 것이 유용하다는 것을 알지만 이 수식어로 무엇을 사용하는 것이 좋은지는 잘 몰랐습니다. 헝가리안 표기법은 이 수식어로는 변수가 사용되는 영역의 종류를 지정하는 것이 적당하다는, 경험에서 우러나온 지혜를 알려줍니다.

컴파일러 형 검사 남용

사실 변수의 종류를 구분하기 위해 별도의 타입을 만들고 컴파일러에게 이러한 타입 체크를 맡겨버리는 방법도 있습니다. 클래스가 하는 일이 그것이죠. 하지만 기본적인 프리미티브 타입에 대해서까지 이러한 방식을 사용하는 것은 코드 작성시 소모되는 오버헤드가 많아 생산성을 떨어뜨리게 될 것 같습니다. 일종의 컴파일러 형 검사 남용이죠. 형 검사는 형 검사일 뿐 로직을 보증할 수는 없습니다. 결국 어느정도의 복잡도는 프로그래머 머리속에서 처리되어야 합니다.