[클린코드] 2장 Meaningful Names

의도를 드러내는 이름

좋은 이름을 생각하는 데는 시간이 들지만 그보다 더 많은 시간을 아껴줄 것이다

개발 중에 더 적합한 이름을 찾았다면 바로 바꿔주자.

변수, 함수, 클래스 등 모든 것의 이름은

• 왜 만들어졌는지
• 하는 일이 무엇인지, 그리고
• 어떻게 쓰이는지에 대한 답이 될 수 있어야 한다.

주석이 필요한 이름은 의도를 드러내는데 실패한 이름이다.

중요한 것은 코드의 간결성이 아니라 코드의 함축성이다.

public List<int[]> getThem() {
	List<int[]> list1 = new ArrayList<int[]>()'
	for (int[] x: theList)
		if (x[0] == 4)
			list1.add(x);
	return list1;
}

 

위의 코드를 다음과 같이 바꿔보면 이름의 함축성이 얼마나 중요한지 알 수 있다.

public List<int[]> getFlaggedCells() {
	List<int[]> flaggedCells = new ArrayList<int[]>()'
	for (int[] cell: gameBoard)
		if (cell[STATUS_VALUE] == FLAGGED)
			flaggedCells.add(cell);
	return flaggedCells;
}

코드의 간결성은 똑같고 이름만 의도를 드러내게 수정했을 뿐인데

코드를 이해하는 게 훨씬 쉬워졌음을 알 수 있다.

 

허위 정보에 주의하자

• 본래 의도와 다르게 해석될 수 있는 단어들을 피해야 한다.
  • hp, aix, sco처럼 유닉스에서 원래 쓰이던 단어를 쓰면 헷갈리게 된다.
  • 배열이 아니라면 List를 붙이지 말자.
  • accoutList가 배열이 아니라면 accouts, accountGroup 등으로 써야 한다.
• 작은 변형을 준 이름들을 지양하자.
  • controllerForEfficientHandlingOfString과 controllerForEfficientStorageOfString처럼
    비슷한 이름들을 가진 변수를 쓰는 것은 좋지 않다.
  • 특히 요즘에는 IDE의 기능으로 알파벳 몇 개로 선택 가능한 변수들을 띄워주기 때문에 더 위험하다

의미를 가지고 이름을 구분하자

• 단순히 컴파일러/인터프리터가 에러를 만드는 것을 방지하기 위해
  뒤에 숫자를 붙이거나 다른 단어를 덧붙이는 것은 스스로 문제를 만들어내는 것과 같다
  mark1, mark2, productInfo, productData
  
• 두 변수가 다른 이름을 가져야 한다는 것은 다른 의미를 가진다는 뜻이다
• Customer와 CustomerObject가 있을 때 손님의 결제기록을 보려면 어떤 객체를 봐야할 지 알 수 없다
• 이름을 보고 독자가 그 차이를 알아차릴 수 있어야 한다

발음할 수 있는 이름을 짓자

프로그래밍은 혼자 하는 게 아니다

검색할 수 있는 이름을 짓자

• 한 글자 이름, 숫자 이름을 지양하자
• 저자는 짧은 method의 지역변수명일 때만 한 글자 이름이 용인된다고 한다(for 반목문의 i, j같은 것)

이름을 암호화하지 말자

• 접두사를 쓰지 말자. 코드에 익숙해질수록 접두사를 무시하게 된다

추측하게 하지 말자

• 변수명을 보고 독자가 이건 ‘exampleData’를 뜻하는 거구나! 하고 해석하게 하지 말자
• 문제와 관련된 혹은 해결책과 관련된 용어를 쓰지 않기 때문이다
• use neither problem domain terms nor solution domain terms
• 한 글자 이름을 지어서 나타나는 문제다(짧은 반복문이 아닌 곳에서)
• 다른 사람이 이해할 수 있는 코드를 쓰는 것이 중요하다

클래스나 객체명은 명사(구)여야 한다

• Customer, WikiPage, Account, AddressParser는 되고
• Manager, Processor, Data, Info는 안 된다

메소드명은 동사(구)를 쓴다

• postPayment, deletePage, save
• accessors, mutators, predicates는 get/set/is같은 접두사를 가진다
• 생성자를 덮어쓸 때는(overload) static factory method의 이름에서 인자를 설명한다
• Complex.FromRealNumber(23.0)

유머를 넣으려고 하지 말고 간결하게 이름을 짓자

Say what you mean. Mean what you say.

 

한 개념당 하나의 단어를 사용한다

DeviceManager와 ProtocolController가 있다면

• 두 객체가 다른 타입이며 다른 클래스를 가지고 있을 거라고 생각하게 된다.
• 왜 둘 다 Manager이거나 Controller가 아닌지 생각하게 된다

말장난을 하지 말자

• 하나의 단어를 두 가지 목적으로 쓰지 말자
• add가 두 값을 이어서 하나의 새로운 값을 리턴하는 메소드로 쓰였다면
• 배열에 파라미터를 추가할 때는 add가 아니라 insert, append 같은 단어를 쓰는 게 맞다

해결책과 관련된 이름을 쓰자

• 코드를 읽는 사람은 결국 개발자다.
• 개발자가 알만한 CS 용어, 알고리즘 이름 등을 쓰자
• 문제와 관련된 이름을 지어서 당신의 후임이 고객에게 연락하게 만들지 말자
• 대개 기술적인 이름을 짓는 것이 옳은 방법이다

문제와 관련된 이름을 쓰자

• 개발과 관련한 용어가 없다면(해결책과 관련된 이름이 없다면)
• 문제와 관련된 이름을 사용하자
• 해결책 관련 개념과 문제 관련 개념을 잘 구분하는 것도 좋은 개발자가 할 일이다

❓Solution Domain과 Problem Domain의 개념 차이

문맥을 더해주자

• 이름만으로 의미를 더해주는 것은 대개 충분치 않다
• 클래스, 함수 등으로 문맥을 더해줬을 때 의미가 잘 드러난다
• 그런 영역을 추가해줄 수 없을 때는 접두사라도 더해주자

무의미한 문맥을 더하지 말자

• 서비스의 이름이 DemoApplication이라고 모든 클래스명을 DA로 시작하는 것이 무의미한 문맥.
• accountAddress, customerAddress는 Address라는 클래스의 인스턴스명으로 적절하다.
• 이를 각각의 클래스명으로 쓰는 것은 좋은 생각이 아니다.

동료 개발자가 싫어할 거라고 생각하면서 더 나은 변수명으로 고치는 것을 주저하지 말자

 

---

변수명에는 왜 만들어졌는지, 하는 일이 무엇인지, 그리고 어떻게 쓰이는지에 대한 답이 될 수 있어야 한다라고 했는데

너무나 방대한 개념이 이름에 들어가야 해서 당황스럽다

난 큰 고민을 하지 않고 변수명을 지었던 것 같다

그래서 작은 변형을 준 변수들도 많고

한 개념에 하나의 단어를 쓰고 있지도 않은 것 같다

사실 이 챕터가 요구하는 바를 모두 충족시키는 변수명을 짓는 것은 어렵겠지만

최소한 한 개념당 하나의 단어를 쓰는 것 정도는 지켜야 할 것 같다

1장에서부터 저자가 강조하는 코드가 마치 글처럼 읽혀야 한다는 것이

뭔가 추상적인 개념으로는 이해가 가는데

실제로 어떤 모습이어야 하는지는 아직 잘 모르겠다