1. 의도를 분명히 밝혀라.
좋은 이름으로 절약하는 시간 > 좋은 이름을 위해 고민하는 시간
존재 이유, 수행기능, 사용방법들을 알기 위한 주석이 필요하다면 이름으로 의도를 충분히 드러내지 못한 것이다.
2. 그릇된 정보를 피하라.
나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하면 안됨.
(ex. hp = 유닉스 운영체제의 종류. 직각삼각형의 빗변(hypotenuse)를 hp라고 표현하면 그릇된 정보를 전달할 가능성이 있다.)
List 자료형을 사용하지 않는다면, accountList처럼 이름에 List를 사용하면 안된다. 단순히 accounts면 충분.
(List 자료형도 List를 붙이는 것은 좋지 않다.)
유사한 개념은 일관성있는 유사한 표기법을 사용한다.
어디는 addNumber(), 어디는 putNumber() 이렇게 중구난방하게 사용하면 안된다.
l, O는 숫자 1, 0과 비슷하기에 잘못된 정보를 전달할 수 있는 예이다.
3. 의미있게 구분하라.
불용어를 붙인 명명 은 쓰면 안된다.
(ex) a, an, the, 연속된 숫자, Info, Data, 변수에 variable) -> NameString을 생각해 보자. String이 의미가 있는가?
a, an, the들은 아무 의미가 없고, Info, Data는 의미가 불분명하다.
좋은 예) source, destination 등을 붙인 예
4. 발음하기 쉬운 이름을 사용하라.
내가 짠 코드를 다른 사람에게 설명하기 쉽고,
하나의 코드로 협업할 때 쉬운 의사전달을 위해 발음하기 쉽게 이름을 짓는다.
5. 검색하기 쉬운 이름을 사용하라.
숫자 하나, 알파벳 e같은 이름은 많은 이름들에 포함되고, 검색할 때 난잡하게 검색된다.
이름의 길이는 그 이름이 쓰이는 범위에 비례해서 커야 한다.
이름이 길 수록, 프로그램에 그 이름이 유일해지고, 검색하기도 편하다.
6. 인코딩을 피하라.
헝가리안 표기법은 쓰지 않는다.
멤버변수에 접두어를 붙이지 않는다. (ex) 멤버변수 앞의 m_)
인터페이스 이름은 I 접두어를 붙이지 않는다.
(도형을 생성하는 인터페이스 Abstract 팩토리 ShapeFactory를 만들 때)
(IShapeFactory보다 ShapeFactory가 좋다)
구현하는 구체 클래스(concrete class)에 ShapFatoryImpl가 낫다.(이 또한 구분할 수 있는 적절한 이름이 있는게 좋다.)
7. 자신의 기억력을 자랑하지 마라.
독자가 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수이름은 안좋은 거다.
자기만 알고 기억하는 변수명을 쓰지 마라.
범위가 좁고, 충돌이 발생하지 않는 루프에서 반복 횟수를 세는 변수(i, j, k)를 제외하면 한 글자 변수는 쓰면 안된다.
8. 클래스 이름
명사, 명사구를 사용한다.
좋은 예 : Customer, Account, AddressParser
안좋은 예 : Manager, Processer, Data, Info
9. 메서드 이름
동사, 동사 구
접근자 접두어 : get
변경자 접두어 : set
조건자 접두어 : is
좋은 예 : postPayment, deleteMessage, save
생성자를 Overloading할 때에는, 정적 팩토리 메서드를 사용한다.
Car sonata = Car.FromCarName("소나타");
처럼 어떤 객체를 어떻게 생성하는지 한눈에 볼 수 있다.
유틸성 클래스로써 객체생성을 제한할 때에는 기본 생성자를 private로 선언할 수 있다.
10. 기발한 이름은 피하라.
농담으로 기괴한 이름 짓지 마라.
11. 한 개념에 한 단어를 사용하라.
프로그램 전반에서 데이터를 검색하여 결과값을 받는 메소드는 fetch, retrieve, get같은 메소드 이름을 쓸 수 있지만, 한 프로그램에서는 한 단어를 통일하여 사용한다.
IDE에서는 메소드를 입력할 때, 몇 글자를 입력하면 자동완성리스트를 쫙 띄워준다. 주석을 보지 않고 그 메서드 이름들만 보고 어떤 메서드가 어떤 일을 하는지 알 수 있어야 한다.
(또다른 예 : controller, manager, driver 등을 섞어 쓰는 경우)
12. 말장난을 하지 마라.
한 단어로 여러 개념을 표현하면 안된다.
add 메서드를 두 매개 변수를 하나로 합쳐서 반환하는 메서드에 사용했다면,
집합에 하나의 데이터를 추가하는 메서드는 add로 지으면 안된다. insert, append 등 다른 단어를 사용하여 구분해야 한다.
13. 해법 영역에서 가져온 이름을 사용하라.
해법 영역 : 우리는 프로그래머기 때문에, 프로그래머가 자주 쓰는 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 같은 것들.
예를 들어 데이터를 받아 저장하다가 먼저 들어온 데이터를 반환하는 메소드라면, [queue]를 쓸 수 있다.
14. 문제 영역에서 가져온 이름을 사용하라.
적절한 프로그래머 용어가 없다면, 문제 영역(자동차 관리 프로그램이라면 자동차 관련 용어)에서 가져온 이름을 사용한다.
15. 의미있는 맥락을 추가하라.
이름은 클래스 안에서, 메소드 안에서, 함수 안에서 맥락을 가진다.
number라는 변수가 thereAreNoLetter()라는 메서드 안에서 쓰인다면, 글자의 수라는 맥락을 가지게 된다.
클래스와 메서드를 적절히 나눔으로써, 맥락을 가질 수 있다.
맥락을 부여하기 힘들 때에는, 접두사를 붙인다.
phoneNumber와 같이, 접두사로 의미있는 맥락을 추가하여 알아보기 쉽게 할 수 있다.
16. 불필요한 맥락을 없애라.
고급 휘발유 충전소(Gas Station Delux) 에플리케이션을 개발 할 때,
모든 클래스 이름을 GSD로 시작하는 것은 좋지 않다. GS까지만 치고 자동완성을 하려고 보면, 모든 클래스가 열거된다.
의미를 분명히 하기 위해서는 긴 이름이 짧은 이름보다 좋지만,
의미가 분명하다면, 긴 이름보다는 짧은 이름이 좋다.
하나의 예로, 고객 계좌 클래스를 만들 때에 Account는 클래스 이름에 적절하고, customerAccount는 인스턴스 변수 이름에 적절하다.