소스코드리뷰(I) 변수명의 명명법에 숙달하라

한때 미국 마이크로소프트사의 한 헝가리 출신의 프로그래머가 변수명을 독특하게 붙였고, 버그가 적었다는 점을 통해서 빌 게이츠씨가 회사내 규정으로 정하게 되었다는 헝가리안 표기법이 있다. 윈도용 API로 제공되는 함수와 변수형이 헝가리안 표기로 되어 있어서 접두어 암호를 해독하느라 많은 수고가 필요하다.

명명법은 필요한가?

여기서는 그 수법을 추천하지는 않겠지만, 변수명을 적절하게 정하는 것은 에러를 미연데 방지하게 되고 소스코드의 가독성을 높여준다.  

C/C++로 프로그램을 하는 경우에는 그 제공되는 라이브러리 자체가 암호처럼 되어 있어서 변수명도 암호처럼 붙이는데 익숙하다.

Pascal/FORTRAN/HTML은 대소문자를 구별하지 않기 때문에 소스에 대소문자가 혼용되는 경우가 종종 발견된다.(컴파일이 되니까 개발자가 아무 생각이 없다.)

예를 들어 atoi, atof같은 함수가 C/C++에서 흔히 쓰이는 명칭이다. 네트워크용API도 사정은 비슷하다.

파스칼(델파이)은 StrToInt, IntToHex등으로 비교적 약자를 쓰지 않기 때문에 함수명이 읽기가 쉽다. 이느 소스의 가독성 향상을 가져온다.

대개의 회사는 - 아마추어 집단이 아닌 이익집단이기 때문에 - 팀으로 구성되고 업무분장을 위해서라도 코딩 규약을 정해서 변수명의 명명법을 규정한다. 이 규정은 대개 업계의 큰 형님, 마이크로소프트의 추천 사항을 받아 들여서 접두어를 3-4글자로 축약한 암호를 외는 것으로 시작한다. 한편 요새 유행하는 Java는 다른 성격의 명명법을 추천하고 있다. 변수형이 대부분 클래스 형이기 때문에 C에서 보는 듯한 접두어로 변수명을 축약한다면 더 알기 어려워지기 때문이다.

(보라색 꽃: 이 꽃의 이름을 몰라서 그냥 보라색 꽃이라고 썼다. 이름을 붙이는 것은 이름을 외는 것보다 어렵다.)

코딩 규약을 제대로 파악하여 규칙을 준수하라.

직업으로 소스코딩을 하는 경우에는 이래야 가장 기본적으로 일차적인 소스리뷰의 준비가 된다고 말할 수 있다. 적지 않은 리뷰시간에 명명법 강의만 하다 말수는 없는 것이다.

변수명을 붙일때 일관성을 유지하라.

사람에 따라 스트링변수에 sz 이나 str을 붙이는 습관이 있는데 가급적 자신은 한가지로 일관된 명명법을 유지하라.

자연어에 가깝게 변수명을 사용하라.

예를 들어 논리형(boolean) 변수라면 IsNoun, IsAdjective 형태가 자연스럽다. IsCheck은 금물이다. 오히려 분사 형태인 IsChecked 라면 괜찮다.

  a) 프로퍼티는 명사형, 형용사형의 단어가 좋다. 예) Caption, Title, Visible

  b) 메소드는 동사형, 동사+명사형이 좋다. 예) GetTitle, Move

  c) 이벤트는 동사형, 분사형 또는 명사+동사형이 좋다. 예) OnClick, OnSingularCheck

    Java의 인터페이스로 이벤트를 구현하려 하는 경우도 이에 해당한다.

의미 없는 변수에는 의미있는 단어를 사용하지 말라.

루프의 인덱스로 사용하면서 인덱스 변수를 nLoopIndex, nFirstLoop등의 긴 변수명을 쓰지 말고 간단히 K, L, N, M(또는 k, n, m)을 사용하라. 인덱스로 "i"를 쓰는 것은 매우 오랜 역사가 있지만 가독성이 떨어지기 때문에 사용금지를 권한다. J의 경우 시선이동이 왼쪽으로 되돌아 가기 때문에 고속으로 소스를 이해하는 데는 적합하지 않다. "i"와 혼돈되는 소문자"EL(l)"도 사용을 금한다. 

수학함수 등의 변수파라미터는 N, X, S 등도 한글자로서 충분히 의미가 전달된다.

각 컴파일러에는 기본적으로 라이브러리가 제공하는 도움말, 문헌이 있기 마련이다. 라이브러리 개발자(그들 중에는 고수가 많다.)들이 사용하는 변수명, 파라미터 명명법을 참조하는 것도 좋은 참고사항이 된다.