의도를 분명히 밝혀라

그릇된 정보를 피하라

의미 있게 구분하라

Product라는 클래스가 있다고 가정하자. 다른 클래스를 ProductInfo 혹은 ProductData라고 부른다면 개념을 구분하지 않은 채 이름만 달리한 경우다. Info나 Data는 a, an, the 와 마찬가지로 의미가 불문명한 불용어다. a나 the와 같은 접두어를 사용하지 말라는 소리가 아니다. 의미가 분명히 다르다면 사용해도 무방하다.

인코딩을 피하라

헝가리식 표기법

헝가리식 표기법은 비합리적이다. 옛날에는 컴파일러가 타입을 점검하지 않았으므로 프로그래머에게 타입을 기억할 단서가 필요했다.

요즘은 컴파일러가 타입을 기억한다. 특히 객체는 강한 타입이며, IDE는 컴파일 하지 않고도 타입 오류를 감지한다.

인터페이스 클래스와 구현 클래스

도형을 생성하는 ABSTRACT FACTORY를 구현한다고 가정하자. 이 팩토리는 인터페이스 클래스다. 구현은 구체 클래스에서 한다. 그렇다면 두 클래스 어떻게 지어야 좋을까? IShapeFactory와 ShaeFactory? 개인적으로 인터페이스 이름은 접두어를 붙이지 않는 편이 좋다고 생각한다. 접두어 I는 주의를 흐트리고 과도한 정보를 제공한다. 그래서 인터페이스 클래스 이름과 구현 클래스 이름 중 하나를 인코딩해야 한다면 구현 클래스 이름을 택하겠다. ShapeFactoryImp나 심지어 CShapeFactory가 IShapeFacotry보다 좋다.

클래스 이름

클래스 이름과 객체 이름은 명사나 명사구가 적합하다. Customer, WikiPage, Account, Addressparser등이 좋은 예다. Manager, Processor, Data, Info등과 같은 단어는 피하고, 동사는 사용하지 않는다.

불필요한 맥락을 없애라

고급 휘발유 충전소 (Gas Station Deluxe)라는 애플리케이션을 짠다고 가정하자. 모든 클래스 이름을 GSD로 시작하겠다는 생각은 바람직하지 못하다. IDE에서 G를 입력하고 자동 완성 키를 누르면 IDE는 모든 클래스를 열거한다.

나중에 다른 고객 관리 프로그램에서 고객 주소가 필요하다. GSDAccountAddress 클래스를 사용할까? 이름이 적절하지 못하다.

일반적으로는 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다. 이름에 불필요한 맥락을 추가하지마라.