1. 일반적인 개념의 특별한 경우로 이름을 붙인다.

Calendar 는 특정한 위치에서 날짜와 시간을 나타내는 시스템이다. 한국에서 지금 쓰는 날짜 시스템은 일반적인 Calendar를 확장한 GregorianCalendar로 이름 붙일 수 있다. 비숫하게 JulianCalendar나 ChineseCalendar와 같은 것도 만들어 낼 수 있을 것이다.

2. 가장 중요한 특징만을 나타내도록 이름을 붙인다.

이름은 특징이 충분히 들어나도록 지어야 하지만 다른 개체들에 알리지 말아야 하거나 구현 중에 바뀔 수 있는 요소들이 포함되도록 하여서는 안된다.

예를 들어 일정 시간이 되면 뭔가 시그널을 주는 것에 이름을 붙일 때 MillisecondTiemrAccurateWithinPlusOrMinusTwoMillisecons 라고 해야하나 아님 그냥 Timer 라고만 하면 되나? 앞으로 전혀 바뀌지 않으거라면 모르되 구현의 구체적인 내용을 이름에 포함하는 것인 좋지 않다. 이렇게 하면 장차 이름과 구현을 바꾸기가 너무 어렵게 된다.

3. Service provider 에는 "worker" 이름 체계를 사용한다.

작업 이름 뒤에 er을 붙여 그것을 하는 것을 나타내는 것이 영어의 관용 어법이다. 이런 형식의 이름을 붙여 놓으면 그것이 뭘 하는지 분명하게 알 수 있게 된다. 어떤 서비스를 제공하는 것들은 "worker", "doer", "mover", "shaker" 같은 형식으로 이름을 짓는다.

자바에 이런 이름들이 많다. StringTokenizer, SystemClassLoader, AppletViewer 등등.

"worker" 형식의 이름이 마음에 들지 않으면 CORBAR에서 처럼 "Service"란 단어를 뒤에 붙이는 것도 고려할 수 있다. 예를 들어, "TransactionService", "NamingService" 등등.

4. 행동을 제약하지 않도록 이름을 붙인다.

이름을 붙일 때 너무 작은 범위의 행동만을 하도록 붙여 놓으면 나중에 기능을 추가할 때 애를 먹게 된다. 고객의 거래 내역을 기록하는 클래스 이름으로 Account와 AccountRecord 두 이름을 놓고 고민한다고 해보자. AccountRecord라고 하면 어감상 거래 내역을 담고있는 information holder만으로 여겨져서 앞으로 확장이 곤란하다. 하지만 Account 라고 붙여 놓으면 이 내역에 따라 어떤 행동을 할 수 있을 것으로 판단할 수 있다.

5. 사용되는 시점을 잘 고려하여 이름을 짓는다.

처음 하는 몇가지 일만 보고 이름을 지어 놓으면, 그것이 나중에 딴일을 하게 될 때 이름이 영 어색해 진다. 어플리케이션을 초기화하여 론칭한 후 외부 이벤트를 모니터하는 개체의 이름을 짓는다고 해보자. 이때 이름을 ApplicationInitializer라고 해 놓으면 어플레키션이 잘 돌아가는지 점검하는 역할을 부여할 때 이름이 어색해 진다. 두 기능을 모두 고려하여 ApplicationCoordinator라고 이름 짓는게 좋다.

6. 현재 디자인 컨텍스트에 맞는 이름을 붙여라.

프로그램을 한다 하더라도 환경이 달라지면 이름을 붙이는 컨텍스트로 달라진다. 이걸 고려하지 않고 이름을 붙이면 그 컨텍스트에서 일하는 다름 사람이 보기에 아주 괴상망측한 이름이 되기 쉽다. 예를 들어 Smalltalk를 쓰는 사람은 Java로 작업할 때 기존 작업 습관을 버리기가 매우 어렵다. Java 클래스들이 뭔가 다르리라고 짐작은 하지만 Smalltalk에는 항시 이용하는 Dictionary 클래스가 추상 클래스라는 걸 알면 아주 놀라게 된다.

7. 같은 이름을 여러번 쓰지 마라.

이름은 하나의 컨텍스트에서 하나의 의미만을 갖도록 한다. 같은 이름을 맥락이 다른 여러 곳에서 쓰지 않도록 주의한다.

8. 이름이 충돌하면 접두어를 붙여본다.

아주 적당한 이름을 골랐는데 그것이 다른 것의 이름이랑 충돌한다 해 보자. 이런 경우 특징을 잘 나타내는 형용사 같은 것을 앞에 붙여 충돌을 해결할 수 있다. 자바로 작업을 하면서 뭔가 특성을 나타내는 것에 이름을 붙일 때 Property라고 이름을 붙이면 이미 있는 시스템 클래스 이름이랑 겹친다. 만약 거래 특성을 나타내는 것이라면 TransactionProperty와 같은 이름을 붙여 충돌을 피할 수 있다.

9. 이름이 충돌하면 동의어를 붙여본다.

동의어를 붙여보는 것도 아주 좋은 방법이다. 하지만 동의어란 것이 뉘앙스가 조금씩 다르기 때문에 항상 꼭 맞는 것을 고를 수는 없다. Property 예를 다시 들자면, property의 동의어로 characteristic, attribute, quality, feature, trait 같은 것이 있는데, attribute이나 feature 같은 것이 좋아보이고 characteristic은 너무 길고, quality는 아주 이상하다.

10 . 쉽게 이해할 수 있는 이름을 붙인다.

너무 간결한 이름을 붙이거나 약어나 암호를 쓰는 것을 피한다. 이렇게 하면 나중에 자신도 못알아볼 뿐 아니라 다른 사람이 무슨 뜻인지 알아보기도 힘들다. 예를 들어 Acct라고 이름 붙이기 보다는 Account라고 이름을 붙이는 게 더 낳다.