코드가 하는 일을 이해하기 훨씬 쉬워지며 코드가 할 일을 해석하는 시간이 상당히 줄어든다.
List<Account> accountList;
// 리스트가 아닌데 List란 네이밍을 사용하는 것은 적절하지 않음
Account[] accountList;
// 아래처럼 List를 사용하지 않고 이름을 지어야 함
Account[] accounts;
Account[] accountGroup;
// 일관성이 없는 네이밍
public void adminCreate();
public void createUser();
컴파일러와 인터프리터만 통과하는 코드를 짜려고 하지 말아라.
연속된 숫자
를 붙이거나 불용어
를 추가하는 방식은 적절하지 않다.
불용어 : 분석에 큰 의미가 없는 단어
// 해석에 큰 차이가 없는 네이밍 모음
String idString;
String id;
getAccount();
getAccountInfo();
char c1;
char c2;
String message;
String theMessage;
과도한 축약은 의미 해석도 힘들게 만들고 발음하기도 힘들게 만든다.
usrAddrChgDt;
userAddressChangeDate;
숫자나 문자 하나로 이루어진 변수는 검색하기 매우 어렵다.
// 어떤 것이 더 검색하기 쉬울까?
int s;
int sum;
int MAX_DAYS_TO_WORK = 5;
5
네이밍에 타입, 멤버 변수 접두어(m_), 인터페이스 클래스 접두어(I)는 필요하지 않다.
특히 인터페이스 클래스와 구현 클래스를 구분할 때는 구현 클래스에 인코딩하는 편이 낫다.
// 구현 클래스에 인코딩하기
class LoggingImp;
class CLogging;
LoginUser loginUser;
loginUser = LoginUser.of(User user);
// 섞어서 사용하지 말 것
public void createProd();
public void addProd();
// 하지만 create와 add의 동작이 다를 때는 사용 가능
// create : 새로 생성
// add : 원래 있는 거에 추가
어차피 이 코드를 읽을 사람은 프로그래머라는 것을 기억하기.
적합한 기술 이름을 이용하자. (ex. 디자인 패턴 이름)
의미를 더욱 분명하게 하기 위해서라도 어떤 동작을 하는 부분을 함수로 선언해서 빼낸다. 그리고 그 함수 이름을 적절학게 지어준다.
// 이 함수가 동작 방식을 더 확실하게 알 수 있음
public String getUserNameFromAcessToken(String accessToken)
{
User user = decodeAccessToken(accessToken);
return user.getUserName();
}
public String getUserNameFromAcessToken(String accessToken)
{
// decode access token code
.
.
// get userName
.
.
return userName;
}
쇼핑몰 서버를 만들 때 모든 변수에 ShoppingMall이나 SM을 붙일 필요는 없다.