계속 수정됩니다.
의도를 분명히 밝혀라
의도가 분명한 이름은 정말로 중요하다.
변수나 함수 그리고 클래스 이름은 다음과 같은 굵직한 질문에 모두 답해야 한다.
변수(혹은 함수나 클래스)의 존재 이유는? 수행 기능은? 사용 방법은?
따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.
public List<int[]> getThem() {
List<int[]> list1 = new ArrayList<int[]>();
for (int[] x : theList)
if (x[0] == 4)
list1.add(x);
return list1;
}코드가 하는 일을 짐작하기 어렵다. 문제는 코드의 함축성이다.
코드 맥락이 코드 자체에 명시적으로 드러나지 않는다.
- theList에 무엇이 들었는가?
- theList에서 0번째 값이 어째서 중요한가?
- 값 4는 무슨 의미인가?
- 함수가 반환하는 리스트 list1을 어떻게 사용하는가?
public List<int[]> getFlaggedCells() {
List<int[]> flaggedCells = new ArrayList<int[]>();
for (int[] cell : gameBoard)
if (cell[STATUS_VALUE == FLAGGED)
flaggedCells.add(x);
return flaggedCells;
}한 걸음 더 나아가, 칸을 간단한 클래스로 만들어도 되겟다.
isFlagged라는 좀 더 명시적인 함수를 사용해 FLAGGED라는 상수를 감춰도 좋겠다.
public List<int[]> getFlaggedCells() {
List<Cell> flaggedCells = new ArrayList<Cell>();
for (Cell cell : gameBoard)
if (cell.isFlagged())
flaggedCells.add(cell);
return flaggedCells;
}이름만 고쳤는데도 함수가 하는 일을 이해하기 쉬워졌다.
이것이 좋은 이름이 주는 위력이다.
그릇된 정보를 피하라
그릇된 단서는 코드 의미를 흐린다.
나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안 된다.
예를 들어 hp, aix, sco는 유닉스 플랫폼이나 유닉스 변종을 가리키는 이름이라 변수 이름으로 적합하지 않다.
여러 계정을 그룹으로 묶을 때 실제 List가 아니라면 accountList라 명명하지 않는다.
accountGroup, bunchOfAccoounts, Accounts 등이 대안이다.
서로 흡사한 이름을 사용하지 않도록 주의한다. 한 모듈에서 XYZControllerForEfficientHandlingOfStrings 라는 이름을 사용하고, 조금 떨어진 모듈에서 XYZControllerForEfficientStorageOfStrings 라는 이름을 사용한다면 두 단어는 너무 비슷하다.
유사한 개념은 유사한 표기법을 사용한다.
일관성이 떨어지는 표기법은 그릇된 정보다.
의미 있게 구분하라
동일한 범위 안에서는 다른 두 개념에 같은 이름을 사용하지 못한다.
컴파일러를 통과시키기 위해 연속된 숫자를 덧붙이거나 불용어(의미가 불분명한 용어)를 추가하는 방식은 적절하지 못하다. 이름이 달라야 한다면 의미도 달라져야 한다.
public static void copyCharas(char a1[], char a2[]) {
for (int i = 0; i < a1.length; i++) {
a2[i] = a1[i];
}
}함수 인수 이름으로 source와 destination을 사용한다면 코드 읽기가 훨씬 더 쉬워진다.
Customer라는 클래스와 CustomerObject라는 클래스를 발견했다면 차이를 알기 힘들다.
발음하기 쉬운 이름을 사용하라
발음하기 어려운 이름은 토론하기 어렵다. 예) genymdhms
검색하기 쉬운 이름을 사용하라
간단한 메서드에서 로컬 변수만 한 문자를 사용한다.
이름 길이는 범위 크기에 비례해야 한다.
변수나 상수를 코드 여러 곳에서 사용한다면 검색하기 쉬운 이름이 바람직하다.
긴 이름이 검색하기 쉽다. 검색하기 쉬운 이름이 상수보다 좋다.
인코딩을 피하라
유형이나 범위 정보까지 인코딩에 넣으면 그만큼 이름을 해독하기 어려워진다.
대개 새로운 개발자가 익힐 코드 양은 상당히 많다. 인코딩 언어까지 익히라는 요구는 비합리적이다.
헝가리식 표기법
요즘은 컴파일러가 타입을 기억하고 강제한다. 변수를 선언한 위치와 사용하는 위치가 멀지 않다.
자바 프로그래머는 변수 이름에 타입을 인코딩할 필요가 없다.
변수, 함수, 클래스 이름이나 타입을 바꾸기가 어려워지며 읽기도 어려워진다.
멤버 변수 접두어
멤버 변수에 m_ 이라는 접두어를 붙일 필요가 없다.
클래스와 함수는 접두어가 필요없을 정도로 작아야 마땅하다.
인터페이스 클래스와 구현 클래스
인터페이스 이름은 접두어를 붙이지 않는 편이 좋다.
IShapeFactory 의 접두어 I는 주의를 흐트리고 과도한 정보를 제공한다.
클래스 사용자가 인터페이스라는 사실을 모르도록 ShapeFactory 로 하고,
구현 클래스 이름을 ShapeFactoryImp, CShapeFactory 등으로 한다.
자신의 기억력을 자랑하지 마라
독자가 코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수 이름은 바람직하지 못하다.
일반적으로 문제 영역이나 해법 영역에서 사용하지 않는 이름을 선택했기 때문에 생기는 문제다.
명료함이 최고다. 남들이 이해하는 코드를 내놓자.
클래스 이름
클래스 이름과 객체 이름은 명사나 명사구가 적합하다.
Customer, WikiPage, Account, AddressParser 등이 좋은 예다.
Manager, Processor, Data, Info 등과 같은 단어는 피하고, 동사는 사용하지 않는다.
앞에서 불용어를 사용하지 말라고 해서 그런 것 같다.
메서드 이름
메서드 일므은 동사나 동사구가 적합하다.
postPayment, deletePage, save 등이 좋은 예다.
접근자(Accessor), 변경자(Mutator), 조건자(Predicate)는 javabean 표준에 따라 값 앞에 get, set, is를 붙인다.
string name = blogger.getName();
blogger.setName("Jun");
if (paycheck.isPosted())
…생성자를 중복정의(overload)할 때는 정적 팩토리 메서드를 사용한다.
메서드는 인수를 설명하는 이름을 사용한다.
정적 팩토리 메서드: 객체를 생성하는 메서드를 static 으로 선언하는 기법
정적 팩토리 메서드
Complex fulcrumPoint = Complex.FromRealNumber(23.0);일반적인 메서드 선언
Complex fulcrumPoint = new Complex(23.0);생성자 사용을 제한하려면 해당 생성자를 private로 선언한다.
기발한 이름은 피하라
이름이 너무 기발하면 저자와 유머 감각이 비슷한 사람만, 그리고 농담을 기억하는 동안만 이름을 기억한다.
특정 문화에서만 사용하는 농담은 피하는 편이 좋다.
의도를 분명하고 솔직하게 표현하라.
한 개념에 한 단어를 사용하라
추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다.
예를 들어 똑같은 메서드를 클래스마다 fetch, retrieve, get 으로 제각각 부르면 혼란스럽다.
메서드 이름은 독자적이고 일관적이어야 한다.
마찬가지로 동일 코드 기반에 controller, manager, driver를 섞어 써도 혼란스럽다.
일관성 있는 어휘는 코드를 사용할 프로그래머가 반갑게 여길 선물이다.
말장난을 하지 마라
한 단어를 두 가지 목적으로 사용하지 마라.
여러 클래스에 add라는 메서드가 생겼을 때 모든 add 메서드의 매개변수와 반환값이 의미적으로 똑같다면 문제가 없다.
하지만 지금까지 구현한 add 메서드는 모두가 기존 값 두 개를 더하거나 이어서 새로운 값을 만들었는데,
새로 작성하는 메서드는 집합에 값 하나를 추가한다면 기존 add 메서드와 맥락이 다르므로 insert나 append라는 이름이 적당하다.
프로그래머는 코드를 최대한 이해하기 쉽게 짜야 한다. 대충 훑어봐도 이해할 코드 작성이 목표다.
해법 영역에서 가져온 이름을 사용하라
독자가 프로그래머이므로 기술 용어를 사용해도 된다.
전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다.
문제 영역에서 가져온 이름을 사용하라
적절한 프로그래머 용어가 없다면 문제 영역에서 이름을 가져온다.
해법 영역과 문제 영역(domain)을 구분할 줄 알아야 한다.
문제 영역 개념과 관련이 깊은 코드라면 문제 영역에서 이름을 가져와야 한다.
의미 있는 맥락을 추가하라
스스로 의미가 분명한 이름이 있다. 하지만 대다수 이름은 그렇지 못하다.
그래서 클래스, 함수, namespace에 넣어 맥락을 부여한다.
모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다.
state 라는 변수 하나만 있으면 주소를 나타내는건지 모른다.
이럴 때는 addrState라 쓰면 맥락이 좀 더 분명해진다.
물론 Address라는 클래스를 생성하면 더 좋다.
private void printGuessStatistics(char candidate, int count) {
String number;
String verb;
String pluralModifier;
if (count == 0) {
number = "no";
verb = "are";
pluralModifier = "s";
} else if (count == 1) {
number = "1";
verb = "is";
pluralModifier = "";
} else {
number = Integer.toString(count);
verb = "are";
pluralModifier = "s";
}
String guessMessage = String.format(
"There %s %s %s%s", verb, number, candidate, pluralModifier
);
print(guessMessage);
}- 함수가 좀 길다.
- 세 변수를 함수 전반에서 사용한다.
함수를 작은 조각으로 쪼개고자 클래스를 만든 후 세 변수를 클래스에 넣자.
그러면 세 변수는 맥락이 분명해진다.
public class GuessStatisticsMessage {
private String number;
private String verb;
private String pluralModifier;
public String make(char candidate, int count) {
createPluralDependentMessageParts(count);
return String.format(
"There %s %s %s%s",
verb, number, candidate, pluralModifier );
}
private void createPluralDependentMessageParts(int count) {
if (count == 0) {
thereAreNoLetters();
} else if (count == 1) {
thereIsOneLetter();
} else {
thereAreManyLetters(count);
}
}
private void thereAreManyLetters(int count) {
number = Integer.toString(count);
verb = "are";
pluralModifier = "s";
}
private void thereIsOneLetter() {
number = "1";
verb = "is";
pluralModifier = "";
}
private void thereAreNoLetters() {
number = "no";
verb = "are";
pluralModifier = "s";
}
}불필요한 맥락을 없애라
일반적으로는 짧은 이름이 긴 이름보다 좋다.
단, 의미가 분명한 경우에 한해서다.
이름에 불필요한 맥락을 추가하지 않도록 주의한다.
accountAddress와 customerAddress는 Address 클래스 인스턴스로는 좋은 이름이나 클래스 이름으로는 적합하지 못한다.
마치면서
좋은 이름을 선택하려면 설명 능력이 뛰어나야 하고 문화적인 배경이 같아야 한다.
우리들 대다수는 자신이 짠 클래스 이름과 메서드 이름을 모두 암기하지 못한다.
우리는 문장이나 문단처럼 읽히는 코드 아니면 (정보를 표시하는 최선의 방법이 항상 문장만은 아니므로) 적어도 표나 자료 구조처럼 읽히는 코드를 짜는 데만 집중해야 마땅하다.
다른 사람이 짠 코드를 손본다면 리팩터링 도구를 사용해 문제 해결 목적으로 이름을 개선하라.
이 장에서 소개한 규칙을 적용해 코드 가독성이 높아지는지 살펴보라.
코드를 개선하려는 노력을 중단해서는 안 된다.
모르는 용어 정리
인수 테스트 케이스(Acceptance Testing): 정보 시스템의 검사 중 하나로서, 해당 시스템이 실제 운영 환경에서 사용될 준비가 되었는지 최종적으로 확인하는 테스팅 단계이다.
메서드 추출 리팩터링(Extract Method): 한 메서드안에 이런저런 세세한 처리가 많다면 그런 처리를 묶어서 나누고 독립된 메서드로 추출하고 추출한 메서드에는 적절한 이름을 붙임.
grep: 유닉스를 위해 만들어진 텍스트 검색 기능을 가진 명령어다. global / regular expression / print 의 앞 글자를 따왔다.
get, fetch, retrieve 의 차이: 미묘한 차이가 있다. 저자가 말하는 대로 한 개념에 한 단어를 사용하자.
작업 큐(JobQueue): 시스템 소프트웨어에서 작업 큐는 실행할 작업을 포함하는 작업 스케줄러 소프트웨어가 유지 보수하는 데이터 구조입니다. (큐에 작업들을 담아뒀다가 빈 스레드에 스케줄링해서 처리하는 방식)
VISITOR 패턴: 방문자와 방문 공간을 분리하여,
방문 공간이 방문자를 맞이할 때, 이후에 대한 행동을 방문자에게 위임하는 패턴이다. 즉, 방문한 '나'가 주체가 되지 않고 방문 공간이 주체가 되는 패턴.
