의도를 분명히 밝혀라
- 변수나 함수 그리고 클래스 이름은 존재 이유, 수행 기능, 사용 방법에 모두 답해야 하며
따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.
- 의도가 드러나는 이름을 사용하면 코드 이해와 변경이 쉬워지므로 정보를 제공하기 위한 코드의 함축성이 중요하다.
// bad
int d; // 경과 시간 (단위: 날짜)
// good
int daysSinceCreation;
그릇된 정보를 피하라
- 그릇된 단어, 흡사한 이름, 일관성이 떨어지는 표기법은 코드의 의미를 흐린다.
// bad
List가 아닐 때 accountList라고 명명하는 것
// good
accountGroup, bunchOfAccounts, Accounts
// bad
// 1과 l, 0과 O
int a = l;
if (O == l)
a = O1;
else
l = 01;
의미 있게 구분하라
- 연속적인 숫자를 덧붙이거나 의미가 불분명한 불용어를 추가하는 방식은 아무런 정보를 제공하지 못하는 이름이다.
- 읽는 사람이 차이를 알도록 이름을 지어라.
// bad
a1, a2, ... aN
// bad
getActiveAcoount();
getActiveAccounts();
getActiveAccountInfo();
moneyAmount와 money
customerInfo와 customer
accountData와 account
theMessage와 message
발음하기 쉬운 이름을 사용하라
- 사람들은 단어에 능숙하므로 발음하기 어려운 이름을 토론하기도 어렵다.
// bad
private Date genymdhms; // generate date, year, month, day, hour, minute, second
// good
private Date generationTimestamp;
검색하기 쉬운 이름을 사용하라
- 문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다는 문제점이 있다.
- 긴 이름이 짧은 이름보다 좋고, 검색하기 쉬운 이름이 상수보다 좋다.
- 간단한 메서드에서 로컬 변수만 한 문자를 사용하는 것은 괜찮지만, 이름 길이는 범위 크기에 비례해야 한다.
// bad
4
5
t[j]
// good
int realDaysPerIdealDay = 4;
const int WORD_DAYS_PER_WEEK = 5;
taskEstimate[j]
인코딩을 피하라
- 이름 길이가 제한된 언어를 사용하던 옛날과 달리, 요즘 나오는 프로그래밍 언어는 훨씬 더 많은 타입을 지원한다.
- 또한 컴파일러가 타입을 기억하고 강제하므로 인코딩할 필요가 없다.
// bad
private String m_dsc; // 설명 문자열 (멤버 변수 접두어 m_)
void setName(String name) {
m_dsc = name;
}
// good
String description;
void setDescription(String description) {
this.description = description;
}
// bad
인터페이스 클래스 - IShapeFactory // 인터페이스 접두어 I
구체 클래스 - ShapeFactory
// good
인터페이스 클래스 - ShapeFactory
구체 클래스 - ShapeFactoryImp, CShapeFactory
자신의 기억력을 자랑하지 마라
- 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다.
- 전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하려는 코드를 내놓는다.
// bad
호스트와 프로토콜을 제외한 소문자 URL을 뜻하는 r이라는 변수
클래스 이름
- 클래스 이름과 객체 이름은 명사나 명사구가 적합하다,
- 특정 단어는 피하며, 동사는 사용하지 않는다.
// bad
Manager, Processor, Data, Info, Save, Delete
// good
Customer, WikiPage, Account, AddressParser
메서드 이름
- 메서드 이름은 동사나 동사구가 적합하다.
- 접근자, 변경자, 조건자는 값 앞에 get, set, is를 붙인다.
- 생성자를 중복정의할 때는 정적 팩토리 메서드를 사용하며 인수를 설명하는 이름을 사용한다.
// bad
Customer, WikiPage
Complex fulcrumPoint = new Complex(23.0);
// good
postPayment, deletePage, save
getName, setName, isPosted
Complex fulcrumPoint = Complex.FromRealNumber(23.0);
기발한 이름은 피하라
// bad
HolyHandGreade // 수류탄
whack
eatMyShort
// good
DeleteItems
kill
Abort
한 개념에 한 단어를 사용하라
- 추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다.
// bad
똑같은 메서드를 클래스마다 fetch, retrieve, get으로 제각각
동일 코드 기반에 controller, manager, driver를 섞어쓰기
// good
fetch
controller
말장난을 하지 마라
// bad
같은 맥락이 아닌데도 add 메서드라는 이름으로 부르기
// good
기존 값 두 개를 더하거나 이어서 새로운 값을 만들 때는 add 메서드
집합에 값 하나를 추가할 때는 insert 또는 append 메서드
해법 영역에서 가져온 이름을 사용하라
- 코드를 읽을 사람도 프로그래머라는 사실을 명심한다.
- 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다.
// good
AccountVisitor // VISITOR 패턴
JobQueue
문제 영역에서 가져온 이름을 사용하라
- 적절한 프로그래밍 용어가 없다면 문제 영역에서 이름을 가져온다.
- 그러면 코드를 보수하는 프로그래머가 분야 전문가에게 의미를 물어 파악할 수 있다.
의미 있는 맥락을 추가하라
- 스스로 의미가 분명한 이름이 아니라면 클래스, 함수, 이름 공간에 넣어 맥락을 부여한다.
- 모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다.
// bad
firstName, lastName, street, houseNumber, city, state, zipcode
// good
addrFirstName, addrLastName, addrStreet, addrHouseNumber, addrCity, addrState, addrZipcode
// very good
Address라는 클래스를 생성하면 변수가 좀 더 큰 개념에 속한다는 사실이 컴파일러에게 분명해짐
public class Address {
private String firstName;
private String lastName;
...
}
불필요한 맥락을 없애라
- 모든 클래스 이름 앞을 같게 맞춰 시작하게 하지 않는다.
- 일반적으로 짧은 이름이 긴 이름보다 좋다.
단, 의미가 분명한 경우에 한해서이며 이름에 불필요한 맥락을 추가하지 않도록 주의한다.
// bad
GSDAccountAddress // GSD (Gas Station Deluxe)
GSD______________
