[Programming] - CleanCode 02. 의미있는 이름


코드는 결국 누군가 읽는 문서이다. 게다가 상대방이 수정을 해야하는 점을 꼭 기억하자.

그렇기에 의미, 의도 전달이 무엇보다 중요하다.

1. 의도를 분명히 밝혀라


주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.

for(int[] x : theList)
	if(x[0] == 4)
		list1.add(x);
	return list1;
  1. theList에는 무엇이 들어있는가? ⇒ gameBoard
  2. theList에 0번째 값이 왜 중요한가? ⇒ STATUS_VALUE
  3. 값 4는 무슨 의미인가? ⇒ FLAGGED
  4. 함수가 반환하는 list1은 어떻게 사용하는가? ⇒ flaggedCells
public List<int[]> getFlaggedCells() {
	List<int[]> flaggedCells = new ArrayList<int[]>();
	for (int[] cell : gameBoard)
		if (cell[STATUS_VALUE] == FLAGGED) //if (cel.isFlagged()) 로 추상화 가능
			flaggedCells.add(cell);
	return flaggedCells;
}

2. 그릇된 정보를 피하라


  1. 나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해서는 안된다.
  2. 실제 List가 아니라면 이름 끝에 List라고 명명하지 말아라. (데이터 타입 혼동이 온다)
  3. 서로 흡사한 이름을 사용하지 않도록 주의 한다.
  4. 유사한 개념은 유사한 표기법을 사용한다.

3. 의미 있게 구분하라


연속된 숫자를 덧붙이거나 불용어 사용을 추가하는 방식은 적절하지 못하다.

이름이 달라야 한다면 의미도 달라져야 한다.

예시) product 클래스가 있을 때

productInfo, productData는 개념을 구분하지 않은채 이름만 달리하는 경우다.

Info , Data는 a, an, the와 마찬가지로 불분명한 불용어다.

읽는 사람이 차이를 알도록 이름을 지어라

4. 발음하기 쉬운 이름을 사용하라

5. 검색하기 쉬운 이름을 사용하라


이름 길이는 범위 크기에 비례해야 한다.

즉, 범위, 여러 파일에서 사용되는 변수라면 이름을 최대한 유니크하게 작성하여 검색을 용이하게 만든다.

6. 인코딩을 피하라


변수 이름에 타입을 인코딩할 필요가 없다.

ex) PhoneNumber, PhoneString; //타입이 만약 바뀌면?…

이제는 과거 처럼 접두어를 붙일 필요없다.

예전에 안드로이드 코드에 다 앞에 m을 붙였던 기억이…

인터페이스와 구현 클래스는 여러 방식이 있지만

IShapeFactory ( interface ) ↔ ShapeFactory (class) 보다

ShapeFactory ( interface ) ↔ ShapeFactoryImple (class) 로 하자.

7. 자신의 기억력을 자랑하지 마라


for 내부에만 잠깐 쓰이는 변수로 i,j,k는 괜찮다

그러나 나머지 영역에서 기억에 의존해야하는 변수 이름을 쓰지 마라.

8. 클래스 이름


명사나 명사구로 작성하자.

9. 메서드 이름


동사나 동사구로 작성하자.

접근자, 변경자, 조건자는 get,set,is를 접두어로 붙이자.

생성자 중복 정의 할때는 정적 팩토리 메서드를 사용한다.

ex) new Complex(23.0) ⇒ Complex.FromRealNumber(23.0)

10. 기발한 이름은 피하라


명료함이 핵심이다.

11. 한 개념에 한 단어를 사용하라


추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다.

예를들어 데이터를 가져오는 함수에서 get,fetch,retrieve 혼용하지 말아라.

12. 말장난 하지 마라


한 단어를 두 가지 목적으로 사용하지 마라.

ex) 어떤 클래스에 add라는 메서드가 생겼다. 모든 add 메서드가 같은 의미 (기존 값 2개를 더하는 의미)라면 괜찮지만 이번에 만든 메서드가 (기존 데이터 뒤에 추가로 데이터를 붙이는 기능) 다른 의미라면 append등 다른 이름을 고려해라.

13. 해법 영역에서 가져온 이름을 사용하라


기술 개념 용어가 필요한 곳은 기술 개념 용어를 사용하라

ex) 큐, 스택, 해쉬 등

14. 문제 영역 (도메인)에서 가져온 이름을 사용하라


해법 영역(기술 파트)와 문제 영역(도메인)을 구분할 줄 알아야 한다.

문제 영역 개념과 관련이 깊은 코드라면 문제 영역에서 이름을 가져와야 한다.

15. 의미 있는 맥락을 추가하라


클래스, 메서드 등의 공간 안에 넣으면 이름의 맥락을 부여하여 분명해진다.

ex) firstName, lastName, street, houseNumber 등을 Address 클래스에 넣으면 명확하게 된다.

16. 불필요한 맥락을 없애라


일반적으로 짧은 이름이 긴 이름보다 좋다. 이름에 불필요한 맥락을 추가하지 않도록 주의하자.

ex) ‘GasStationDeluxe’를 줄여서 GSD라고 클래스 이름을 시작하는 방식은 좋지 않다.

또한, accountAddress와 customerAddress는 Address 클래스의 인스턴스 네임으로는 괜찮으나

클래스 이름으로는 적합하지 못한다.

마무리


이 파트를 읽으며 가장 핵심은

  1. 다른 사람이 읽을 것을 , 수정 할 것을 고려 하여 가독성 있게 이름을 작성해라
  2. 의도가 잘 전달되도록 노력하고 수정하고 수정해라

가장 인상 깊었던 부분은

  1. List라는 이름을 함부로 쓰면 안된다는 부분
  2. add라는 메서드도 다른 곳에서 어떻게 쓰이는지 고려해서 이름을 붙여야 한다는 부분이였다.
  3. 이름의 길이는 사용되는 범위에 비례하게 만들어라. 즉, 검색이 쉽게 만들어라

내 코드 또한 이름이 지금 어떻게 작성되있는지 생각하면 참 부끄러워진다.