의도를 분명히 밝혀라
int d; 위 변수 d의 의미는 무엇일까? - 유추하기 힘들 것이다.
사실 d의 의미는 단위가 날짜인 경과한 시간이다.
int elapsedDays;그렇다면 위의 변수명은 어떤가?
해당 변수는 경과한 날짜라는 것이 명확해졌다.
if(score >= 90) {...}위 90점이 무슨 의미일까?
if(score >= A_GRADE_SCORE) {...}이제 조건문의 정체가 명확해졌다.
public List<int[]> getThem() {...}위 함수의 역할은 무엇인가?
public List<int[]> getFlaggedCells() {...}플래그 칸들을 가져오는 함수구나!
이처럼 개발자는 이름을 잘 지어야 되며, 잘 짓는 것이란 의도를 분명히 밝히는 것이다.
의도가 분명하면 함수가 하는 일을 이해하기 쉽다.
그릇된 정보를 피하라
헷갈릴 수 있는 이름은 지양해야한다.
예를 들어 hp, aix, sco는 유닉스 플랫폼이나 유닉스 변종을 가리키는 이름이기 때문에 변수명으로 적합하지 않다.
직각 삼각형의 빗변인 hypotenuse에 hp라는 약어를 사용하면 독자는 오해할 수 있다.
여러 계정을 그룹으로 묶을 때 List를 사용하는게 아니라면 accountList와 같은 변수명은 적합하지 않다. (자료구조 오해의 소지가 있음)
accountGroup, accounts와 같은 변수명을 사용해야한다.
l이나 O의 사용을 주의하자. 1과 0과 혼돈하기 쉽다.
의미 있게 구분하라
불용어는 아무런 정보를 제공하지 못하므로 생략하는 것이 좋다.
또한 너무 비슷하여 의미의 차이가 모호한 이름들은 사용하면 좋지 않다.
getActiveAccount();
getActiveAccounts();
getActiveAccountInfo();독자는 위 세 함수의 차이를 알 수 있을까?
읽는 사람이 차이를 알도록 이름을 짓자.
발음하기 쉬운 이름을 사용하라
genymdhms라는 함수가 사용한다면, 회의할 때 이 함수를 '젠 와이 엠 디 에이치 엠 에스'라고 발음하거나 '젠 야무다 힘즈'와 같이 발음할 것이다.
이를 generationTimestamp로 변경한다면 '제너레이션 타임스탬프'와 같이 명확하게 발음할 수 있다.
'젠 와이 엠 디 에이치 엠 에스'보다는 '제너레이션 타임스탬프'로 발음하는 것이 더 지적인 대화를 만들어줄 것 같다.
검색하기 쉬운 이름을 사용하라
일주일 중 평일의 수를 5로 사용하면 검색하기 쉬울까?
생각보다 5라는 숫자가 소스코드에 많이 포함되어 있을 수 있다.
이 것을 WORK_DAYS_PER_WEEK로 사용한다면 검색하기 쉬워질 것이다.
합을 계속 누적하는 변수의 이름을 s로 지은다면 검색하기 쉬울까? - sum으로 변경한다면 검색하기 수월하다.
자신의 기억력을 자랑하지 마라
자신만 아는 이름으로 변수를 짓는다면 과연 나중에 해당 변수를 알아볼 수 있을까?
자신도 알아보기 힘든 변수명을 독자가 알아볼 수 있을까?
특히 자신만 기억하고 알아보면 된다고 변수명을 알파벳 한 글자로 짓는 경우가 많은데, 이는 적절치 못하다. (루프 반복 횟수 카운트하는 i, j, k를 제외하고)
전문가 프로그래머는 명료한 이름을 사용해 남들이 이해하는 코드를 내놓는다.
메소드 이름
메소드 이름은 동사나 동사구가 적합하다.
javabean 표준에 따라 다음을 붙인다.
- 접근자(Accessor) : get
- 변경자(Mutator) : set
- 조건자(Predicate) : is
생성자를 중복정의할 때는 정적 팩토리 메소드를 사용한다.
정적 팩토리 메소드는 메소드명을 바꿀 수 있다는 점과 반환 타입의 다양성이라는 장점을 가진다.
한 개념에 한 단어를 사용하라
누구는 fetch, 누구는 retrieve, 누구는 get... 이렇게 사용하면 혼란스럽고 어느 클래스에서 어느 이름을 썼는지 기억하기 어렵다.
controller, manager, driver를 섞어 쓰는 것도 마찬가지일 것이다.
일관성 있는 어휘는 코드를 사용할 개발자가 반갑게 여길 선물이다.
한 단어를 두 가지 목적으로 사용하지 마라
지금까지 add를 두 개를 더하거나 이어서 새로운 값을 만들 때 사용했는데, 새로 작성하는 메소드는 집합에 값 하나를 추가한다.
새로운 메소드에 add를 사용해도 될까? - 아니다. 코드를 이해하기 어렵게 만들 수 있다.
따라서 세로운 메소드의 이름은 insert, append가 적당할 것이다.
독자에게 의미를 해독할 책임이 있는 것이 아닌, 의도를 밝힐 책임이 저자에게 있는 것이 바람직하다.
해법 영역에서 가져온 이름을 사용하라
방문자 패턴에 친숙한 개발자는 AccountVisitor라는 이름을 금방 이해한다.
마찬가지로 개발자는 JobQueue라는 이름의 클래스를 금방 이해할 것이다.
개발자에 익숙한 기술 개념은 그대로 잘 활용하자.
의미 있는 맥락을 추가하라
주소에 사용되는 변수로 firstName, lastName, state, city... 가 있을 때 state만 보고 주소에 사용되는 변수인지 알아차릴 수 있을까?
addrFirstName, addrLastName, addrState, addrCity... 와 같이 의미 있는 맥락을 추가하면 의도를 더 쉽게 파악할 수 있다.
또한 하나의 메소드가 방대해지고 책임이 많아지면 메소드 명만으로 모든 의미를 파악하기 힘들다.
여러 의미있는 메소드명을 가진 메소드들로 쪼갠다면 더 이해하기 쉽고 명확해질 것이다.
불필요한 맥락을 없애라
고급 휘발유 충전소(Gas Station Deluxe)라는 앱을 개발한다고해서 모든 클래스 이름을 GSD로 시작하겠다는 생각은 전혀 바람직하지 않다.
IDE의 클래스 검색기능을 사용할 때 'G'로 검색한다면 모든 클래스가 검색될 것이다.
일반적으로 짧은 이름이 긴 이름보다 좋다. 굳이 포함하지 않아도 의미가 분명하다면, 불필요한 맥락을 추가하지 말자.
