--------------------------------------------------------------------------------------
명칭 작성 원칙에 대한 보충글
--------------------------------------------------------------------------------------

일전에 올린 "델파이 코드 리팩토링"이란 글에서 사용한 코드를 보자.

procedure TForm1.Button1Click(Sender: TObject);
const
  s1 = '하하'; //...
  s2 = '호호'; //...
begin
  if TButton(Sender).Caption = s1 then
    TButton(Sender).Caption := s2
  else
    TButton(Sender).Caption := s1;
end;

이 코드를 본 익명의 독자 중 한사람이 s1과 s2라는 너무 간단한 상수명에 대해서, 이름짓기(Naming) 원칙을 위배했다고 반론을 제기했다. 이 독자는 s1, s2는 너무 암호같은 명칭이라서 그런 반론을 제기한 듯 하다.

그런데, 특정 함수나 클래스의 성격을 잘 의미하는 단어로 명칭을 작성하는 것도 중요하지만, 더욱 중요한 것은 소스 전반에 걸쳐서 모든 명칭이 일관성을 가지는가 이다. 즉 명칭을 작성하는 체계적인 룰이 있는가가 더 중요하다.

VCL 클래스를 보면 델파이를 만든 개발자들이, 상당히 명칭 작성에 일관성을 유지하려 한 노력들이 보인다. 예를 들어, VCL의 여러 콤포넌트 클래스들이 Caption과 Text 속성을 가지는데, 이 속성명들이 어떤 경우에 사용되는지를 잘 보라. VCL 클래스 계층도에서 TCustom... 이란 명칭의 클래스가 어떤 경우 등장하는지를 잘 살펴 보라.

사각형이란 의미로, Rect, Rectangle, Square, Sagak 등의 여러가지 단어 중 하나를 선택할 수 있다. 그런데, 사각형이란 의미로 Rect란 단어를 사용하기로 했다면 모든 소스에서 Rect를 일관되게 사용해야 한다. 어떤 소스에서는 Rect, 어떤 소스에서는 Square를 사각형이란 의미로 사용하면 안된다는 것이다. 같은 의미에 대해서, 각기 다른 단어를 마구 사용하는 것은 소스 가독성에 정말 치명적이다.

아주 편집을 엉망으로 한 컴언어 관련 책에서도, 이런 명칭 일관성 결여를 종종 발견하곤 한다. 예를 들어 object를 지칭할 때, 어떤 페이지에서는 "오브젝트", 어떤 페이지에서는 "객체", 혹은 "개체", "요소" 등으로, 같은 의미에 대해서 다른 단어를 사용하는 것이다. 이런 책은 매우 이해하기가 힘들다. 불행스럽게도 요즘의 컴 관련 책을 보면 이런 황당한 책들을 자주 보게 된다.

이름 짓기 원칙은 어떤 단어를 선택하는 것보다, 잘 정비된 룰에 따르는 일관된 원칙이 있는가가 더 중요하다. 일관된 원칙 아래 작성된 코드는 훨씬 이해하기가 쉽다. 일관성있게 작성된 코드는 그 일관성을 깨닫게 되는 시점부터 소스 이해 속도가 가속화되지만, 일관성이 없는 소스는 처음부터 끝까지 이해하기 힘들다.

어떤 단어를 선택하는지는 그 팀이나 개발자의 자유 의지다. 그러나 명칭을 만들 때, 다음 원칙들 중 어떤 것들을 지키고 있는지 한번 점검해 보라.

1. 명칭 작성이 일관적인가? 즉 사각형은 무조건 Rect인가 아니면 그때 그때 달라요인가? 그때 그때 마구 다르다면 매우 문제가 많다.

2. 명칭을 보는 즉시 클래스명인지, 인터페이스인지, 함수명(혹은 메서드)인지 알 수 있는가? 즉 명칭의 종류를 즉시 알수 있는가?

3. 변수(혹은 객체)명을 보는 즉시, 전역인지, 로칼인지, 클래스의 필드인지 즉각 구분할 수 있는가? 즉 명칭의 지역성을 바로 알 수 있는가?

4. 폼 유닛인지 단독 유닛인지 즉시 구분할 수 있는가? 단독 유닛인 경우 그 유닛이 대충 어떤 용도의 클래스들을 포함하는지 즉각 알 수 있는가?

5. 명칭을 작성할 때, 항상 그 명칭의 지역성을 어디까지 할 것인지 깊이 생각해 보는가? 모든 명칭은 참조가능한 범위가 있는데, 항상 이를 최소화하려 신경 쓰는가?

6. 명칭을 만들 때 아주 구체적인 Casing 원칙(대소문자 혼용하는 원칙)이 있는가?  

프로그램이란, 다른 사람들의 반복적인 일을 분석하여 정형적인 규칙을 찾아 룰을 세우고, 이를 코딩하는 작업이다. 그런데, 내가 만드는 프로그램 자체에 룰이 없다면 어떻게 되겠는가? 이는 큰 모순이다. 프로그램은 룰이 있어야 한다. 룰이 없는 프로그램은 프로그램이 아니라고 한다면 과연 지나친 말일까?