좋은 변수이름 정하기 : 피해야 할 변수 이름

이 게시물은 스티브 맥코넬이 쓴 CODE COMPLETE2에 나온 내용이며 다른 사람들에게도 변수 이름의 중요성과 그 이름을 정하는 데 도움을 주기 위해, 그리고 나 자신도 필요할 때마다 참고하기 위해 쓴다는 것을 알린다.

피해야 할 변수 이름

다음은 피해야 할 변수 이름에 대한 몇 가지 가이드라인이다.

오해의 소지가 있는 이름이나 축약어를 피한다.

이름이 모호하지 않은지 확인한다. 예를 들면 FALSE는 일반적으로 TRUE의 반대말이며 "Fig and Almond Season"에 대한 축약어로는 좋지 않을 것이다.

유사한 의미가 있는 이름을 피한다.

프로그램에 해를 주지 않고 두 변수의 이름을 교환할 수 있다면 이름을 다시 만들 필요가 있다. 예를 들면 input과 inputValue, recordNum와 numRecords, fileNumber와 fileIndex는 의미상 너무 유사해서 이 변수를 같은 코드에서 사용한다면 혼동하기 쉽고 미묘하고 포착하기 어려운 오류가 발생할 것이다.

이름은 유사하지만 의미가 다른 변수를 피한다.

이름은 유사하지만 의미가 다른 두 변수가 있다면 어느 하나의 이름을 다시 만들거나 축약 규칙을 변경하도록 한다. clientRecs와 ClientReps와 같은 이름을 피한다. 이 두 이름은 오직 한 문자만 다르고 그 문자가 어느 것인지도 알아차리기 어렵다. 적어도 두 이름을 다르게 짓거나 시작이나 끝에 차이점을 둔다. 처음 이름보다는 clientRecords와 clientReports가 더 좋다.

 '개'와 '게'처럼 비슷하게 들리는 이름을 피한다. 동음이의어는 코드를 다른 사람들과 논의하려고 할 때 방해가 된다. 'Goal donor'와 'Gold Owner'같은 모호한 발음의 변수를 한 프로그램 안에서, 혹은 클래스 안에서 사용하는 것을 방지하라.

이름에 숫자를 넣는 것을 피한다.

이름에 있는 숫자가 정말로 중요하다면 개별적인 변수 대신 배열을 사용한다. 배열이 부적절하다면 숫자는 더욱 부적절하다. 예를 들면 file1과 file2 또는 total1과 total2는 사용하지 않는다. 항상 1이나 2를 변수 이름 끝에 붙이는 것보다 두 변수를 구별할 수 있는 더 나은 방법을 생각해낼 수 있다. 그렇다고 숫자를 절대로 사용해서는 안 된다고 말할 수는 없다. 현실 세계의 요소(예: 66번 도로나 405번 고속도로 등)들 중에 숫자가 포함된 것도 있다. 하지만 숫자를 포함하는 이름을 생성하기 전에 더 나은 대안은 없는지 고려해 본다.

이름에 철자가 틀린 단어가 없도록 한다.

단어의 철자를 기억하기란 매우 어렵다. 사람들에게 "정확하게" 틀린 철자를 기억하도록 요구하는 것은 지나치다. 예를 들어 세 문자를 절약하기 위해서 highlight를 hilite로 표기한다면 코드를 읽는 사람이 highlight를 어떻게 틀리게 썼는지는 기억하기가 매우 어렵다.

대소문자만으로 변수의 이름을 구분하지 않는다.

C++와 같이 대소문자에 민감한 언어로 프로그래밍하고 있다면 아마도 fired에 대해 frd를 사용하고 final review duty에 대해 FRD를 사용하고 full revenue disbursal에 대해 Frd를 사용하고 싶을지도 모른다. 이러한 실천법은 사용하지 않는다. 이 이름이 고유하기는 하지만, 개별적인 의미를 가진 각 변수의 조합이 제멋대로고 혼란을 줄 수 있다. Frd가 final review dury를 의미할 수도 있고 FRD가 full revenue disbursal을 의미할 수도 있다. 어느 것이 무슨 의미인지 기억하는 데 도움이 될 만한 논리적 규칙이 전혀 없다.

여러 가지 자연어를 사용하지 않는다.

다중 언어를 지원하는 프로젝트에서는 클래스 이름과 변수 이름 등을 포함한 모든 코드에 하나의 언어만 사용하도록 한다. 다른 개발자의 코드를 읽는 것도 어려운 일이지만 외국어로 작성된 개발자의 코드를 읽는 것은 아예 불가능하다.

 더욱 미묘한 문제는 영어의 다양한 변형에서 발생한다. 프로젝트가 영어를 사용하는 여러 국가에서 수행되었다면 한 가지 버전의 영어로 표준화하여 코드가 "color"나 "colour", "check"나 "cheque"에서 어느 것을 사용할지 미리 정해둔다.

표준 데이터형과 변수, 루틴의 이름은 사용하지 않는다.

모든 프로그래밍 언어 설명서는 언어의 예약어와 미리 정의된 이름에 대한 목록을 포함하고 있다. 그러한 언어의 영역을 침범하고 있지 않은지 확인하기 위해서 종종 그러한 목록을 읽어본다. 예를 들면 다음 코드는 PL/I에서는 유효하지만 이처럼 사용하는 것은 어리석음을 증명하는 거나 다름없을 것이다. 애초에 기본적으로 예약어는 변수 선언이 금지돼있지만 극단적인 예를 들어본 것이다.

if if = then then
    then = else;
else else = if;	

변수가 표현하는 것과 전혀 관련이 없는 이름을 사용하지 않는다.

margaret과 pooki와 같은 이름을 프로그램에서 사용한다면 아무도 이해할 수 없을 것이다. 남자 친구의 이름이나 아내의 이름, 좋아하는 맥주의 이름, 그 밖의 현명하지 못한 이름은 프로그램이 정말로 남자친구나 아내, 좋아하는 맥주에 관한 것이 아니라면 변수의 이름으로 사용하지 않는다. 그런 경우라고 하더라도 이 변수는 바뀔 수 있으므로 일반적인 이름인 boyfriend나 wife, favoriteBeer등 일반명사는 사용하는 것이 좋다.

읽기 어려운 문자를 포함하는 이름을 피한다.

너무나 비슷해 보여서 구분하기 어려운 글자를 주의한다. 두 이름의 유일한 차이점이 쉽게 구분되지 않는 문자뿐이라면 이름을 구분하기가 어려울 것이다. 구분하기 어려운 문자 쌍에는 1과 l(소문자L)과 I(대문자 i)가 있고 숫자0과 영어O, 2와 Z, S와 5, G와 6 등이 있다. 이렇게 쓰면 나름대로 구분이 잘 되지만 복잡하디 복잡한 코드로 그득한 파일에서 위 햇갈리는 문자들로 구성된 코드들을 보면 쉽게 구분하기 힘들 것이다.