일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 리스트
- query
- 자료구조
- 빅 오 표기법
- 마크다운
- @NoArgsConstructor
- WebClient
- 계산 검색 방식
- 선형 리스트
- 스택 큐 차이
- 트리
- 쿼리메소드
- CleanCode
- 클린코드
- 클래스
- 쿠키
- java
- @ComponentScan
- 정렬
- 클린
- 배열
- 내부 정렬
- @RequiredArgsConstructor
- 코드
- code
- JsonNode
- 연결 리스트
- 마크다운 테이블
- 인터페이스
- mysql
- Today
- Total
Developer Cafe
클린코드 2장 의미있는이름 본문
의도를 분명히 밝혀라
변수의 존재 이유, 기능, 사용법 등이 변수/함수/클래스명에 드러나야 한다. 따로 주석이 필요하지 않을 정도로.
의미를 함축하거나 독자(코드를 읽는 사람)가 사전지식을 가지고 있다고 가정하지 말자.
// Bad
public List<int[]> getThem() {
List<int[]> list1 = new ArrayList<int[]>();
for (int[] x : theList) {
if (x[0] == 4) {
list1.add(x);
}
}
return list1;
}
// Good
public List<int[]> getFlaggedCells() {
List<int[]> flaggedCells = new ArrayList<int[]>();
for (int[] cell : gameBoard) {
if (cell[STATUS_VALUE] == FLAGGED) {
flaggedCells.add(cell);
}
}
return flaggedCells;
}
그릇된 정보를 피하라
중의적으로 해석될 수 있는 이름 지양하기.
개발자에게는 특수한 의미를 가지는 단어(List 등)는 실제 컨테이너가 List가 아닌 이상 accountList와 같이 변수명에 붙이지 말자. 차라리 accountGroup, bunchOfAccounts, accounts등으로 명명하자
비슷해 보이는 명명에 주의하자.
의미 있게 구분하라(불용어-noise word-를 쓰지 말자)
클래스 이름에 Info, Data와 같은 불용어를 붙이지 말자. 정확한 개념 구분이 되지 않음
- Name VS NameString
- getActiveAccount() VS getActiveAccounts() VS getActiveAccountInfo() (이들이 혼재할 경우 서로의 역할을 정확히 구분하기 어렵다.)
- money VS moneyAmount
- message VS theMessage
발음하기 쉬운 이름을 사용하라
// Bad
class DtaRcrd102 {
private Date genymdhms;
private Date modymdhms;
private final String pszqint = "102";
/* ... */
};
// Good
class Customer {
private Date generationTimestamp;
private Date modificationTimestamp;
private final String recordId = "102";
/* ... */
};
검색하기 쉬운 이름을 사용하라
상수는 static final과 같이 정의해 쓰자.
변수 이름의 길이는 변수의 범위에 비례해서 길어진다.
인코딩을 피하라(변수에 부가 정보를 덧붙여 표기하는 것을 뜻함.)
- 헝가리안 표기법
- 변수명에 해당 변수의 타입(String, Int 등)을 적지 말자
- 맴버 변수 접두어
- 맴버 변수 접두어를 붙이지 말자(???)
- 인터페이스와 구현
- 인터페이스 클래스와 구현 클래스를 나눠야 한다면 구현 클래스의 이름에 정보를 인코딩하자.
자신의 기억력을 자랑하지 마라
독자가 머리속으로 한번 더 생각해 변환해야 할만한 변수명을 쓰지 말라
(eg, URL에서 호스트와 프로토콜을 제외한 소문자 주소를 r이라는 변수로 명명하는 일 등)
똑똑한 프로그래머와 전문가 프로그래머를 나누는 기준 한가지는 "Clarity(명료함)"이다.
클래스 이름
명사 혹은 명사구를 사용하라.(Customer, WikiPage, Account, AddressParser)
Manager, Processor, Data, Info와 같은 단어는 피하자
동사는 사용하지 않는다.
메서드 이름
동사 혹은 동사구를 사용하라.(postPayment, deletePayment, deletePage, save 등)
접근자, 변경자, 조건자는 get, set, is로 시작하자. (추가: should, has 등도 가능)
생성자를 오버로드할 경우 정적 팩토리 메서드를 사용하고 해당 생성자를 private으로 선언한다.
// 첫번째 보다 두 번째 방법이 더 좋다.
Complex fulcrumPoint = new Complex(23.0);
Complex fulcrumPoint = Complex.FromRealNumber(23.0);
기발한 이름은 피하라
특정 문화에서만 사용되는 재미있는 이름보다 의도를 분명히 표현하는 이름을 사용하라
HolyHandGrenade → DeleteItems
whack() → kill()
한 개념에 한 단어를 사용하라
추상적인 개념 하나에 단어 하나를 사용하자.
fetch, retrieve, get
controller, manager, driver
// 한 단어를 두 가지 목적으로 사용하지 말자.
// 아래와 같은 경우에는 list/add를 append 혹은 insert로 바꾸는게 옳겠다.
public static String add(String message, String messageToAppend)
public List<Element> add(Element element)
해법 영역(Solution Domain) 용어를 사용하자
개발자라면 당연히 알고 있을 JobQueue, AccountVisitor(Visitor pattern)등을 사용하지 않을 이유는 없다. 전산용어, 알고리즘 이름, 패턴 이름, 수학 용어 등은 사용하자.
의미 있는 맥락을 추가하라
클래스, 함수, namespace등으로 감싸서 맥락(Context)을 표현하라
그래도 불분명하다면 접두어를 사용하자.
// Bad
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);
}
// Good
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";
}
}
불필요한 맥락을 없애라
Gas Station Delux 이라는 어플리케이션을 작성한다고 해서 클래스 이름의 앞에 GSD를 붙이지는 말자. G를 입력하고 자동완성을 누를 경우 모든 클래스가 나타나는 등 효율적이지 못하다.
위 a처럼 접두어를 붙이는 것은 모듈의 재사용 관점에서도 좋지 못하다. 재사용하려면 이름을 바꿔야 한다.(eg, GSDAccountAddress 대신 Address라고만 해도 충분하다.)
두려워하지 말고 서로의 명명을 지적하고 고치자.
그렇게 하면 이름을 외우는 것에 시간을 빼앗기지 않고
"자연스럽게 읽히는 코드"를 짜는 데에 더 집중할 수 있다.
'책을읽읍시다' 카테고리의 다른 글
클린코드 6장 객체와 자료 구조 (0) | 2022.09.05 |
---|---|
클린코드 5장 형식 맞추기 (0) | 2022.08.05 |
클린코드 4장 주석 (0) | 2022.08.05 |
클린코드 3장 함수 (0) | 2022.08.05 |
클린코드 1장 클린코드 (0) | 2022.08.05 |