의미있는 이름

Sshu Sshu·2022년 8월 16일
0

CleanCode

목록 보기
2/12
post-thumbnail

이름을 잘 짓는 간단한 규칙

1. 의도를 분명히 밝혀라

변수(혹은 함수나 클래스)의 존재 이유, 수행기능, 사용 방법을 이름에서 밝힌다.
따로 주석이 필요하다면 이름에서 의도를 분명히 드러내지 못한 것이다.

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<Cell> getFlaggedCells(){
	List<Cell> FlaggedCells = new ArrayList<Cell>();
		for(Cell cell : gameBoard)
			if(cell.isFlagged())
			flaggedCells.add(cell);
		return flaggedCells;
}

명시적인 이름으로 충분하게 정보를 제공하고 변수, 함수, 클래스가 하는 일을 이해하기 쉽게 만들자.

2. 그릇된 정보를 피하라

그릇된 단서는 코드의 의미를 흐린다.

  • 정확한 의도가 없는 단어를 넣지 않도록 한다.
    예를 들어 여러 계정을 그룹으로 묶을 때, 실제 List유형이 아니라면 이름에 List를 넣지 않는다.
    (실제 List유형이라 해도 컨테이너 유형은 이름에 넣지 않는 것이 좋다.)
  • 서로 흡사한 이름을 사용하지 않도록 주의한다.
  • 유사한 개념은 유사한 표기법을 사용한다. 일관성이 떨어지는 표기법은 그릇된 정보다.

3. 의미 있게 구분하라

연속된 숫자를 덧붙이거나 불용어를 추가하는 방식은 적절하지 못하다.
ex) num1, num2, num3 / data, info, a, an, the
연속된 숫자를 덧붙인 이름은 아무런 정보를 제공하지 않고, 저자의 의도를 파악할 수 없는 이름이다.
불용어는 중복이다. Info, Data, a, an, the 같은 의미가 불분명한 불용어는 개발자를 헷갈리게 한다.

이름이 달라야 한다면 의미도 달라져야한다.
읽는 사람이 차이를 알도록 이름을 지어라

4. 발음하기 쉬운 이름(있는 단어)을 사용하라

사람들은 단어에 능숙하다. 발음하기 어려운 이름은 토론도 어렵다.

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

이름 길이는 범위 크기에 비례해야 한다.
변수나 상수를 코드 여러 곳에서 사용한다면 검색하기 쉬운 이름이 바람직하다.

6. 인코딩을 피하라

문제 해결에 집중하는 개발자에게 인코딩은 불필요한 정신적 부담이다.

  • 헝가리식 표기법
    예전과 달리 프로그래밍 언어나 IDE 등의 발전으로 더이상 변수 이름에 인코딩할 필요가 없어졌다.
    이제는 헝가리식 표기법이나 기타 인코딩 방식이 오히려 방해가 된다.

  • 멤버 변수 접두어
    클래스와 함수는 접두어가 필요 없을 정도로 작아야 하기 때문에 접두어를 쓸 이유가 없다.
    개발자들은 접두어 또는 접미어를 무시하고 코드를 읽는 습관이 있기 때문에, 결국 접두어는
    옛날에 작성한 구닥다리 코드라는 징표가 되었다.

  • 인터페이스 클래스와 구현 클래스
    인터페이스 이름은 접두어를 붙이지 않는 편이 좋다.
    접두어 I (Interface에서 따온)는 주의를 흐트리고 과도한 정보를 제공한다.
    인터페이스 클래스와 구현 클래스 이름 중 하나를 인코딩해야 한다면 구현 클래스 이름을 택하는 게 낫다.

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

코드를 읽으면서 변수 이름을 변환해야 한다면 바람직하지 못한 변수 이름이다.
일반적으로 문제 영역이나 해법 영역에서 사용하지 않는 이름을 선택했기 때문이다.
전문가 프로그래머는 명료함이 최고인 것을 안다.
남들이 이해하는 코드를 내놓는다.

8. 클래스 이름

클래스 이름과 객체 이름은 명사나 명사구가 적합하다.
manager, processor, info, data와 같은 불용어는 피하고 동사는 사용하지 않는다.

9. 메서드 이름

메서드 이름은 동사나 동사구가 적합하다.
접근자, 변경자, 조건자는 표준에 따라 get, set, is를 사용한다.

10. 기발한 이름은 피하라

의도를 분명하고 솔직하게 표현하라

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

추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다.
예를 들어, 똑같은 메서드를 클래스마다 fetch, retrieve, get으로 제각각 부르면 혼란스럽다.
어느 클래스에서 어느 이름을 썼는지 기억하기 어렵다.
동일 코드 기반에 controller, manager, driver을 섞어 쓰면 혼란스럽다.
이름이 다르면 클래스도, 타입도 다르리라 예상하기 때문이다.
일관성 있는 어휘는 코드를 사용할 프로그래머가 반갑게 여길 선물이다.

12. 말장난을 하지 마라

한 단어를 두가지 목적에 사용하지 않는다.
예를 들어 add 가 붙은 메서드는 기존 값 두개를 더하거나 이어서 새로운 값을 만드는데,
새로운 값 하나를 추가하는 메서드를 만들고 같은 맥락이 아닌데도 일관성을 고려해 add 를 붙인다면 말장난이다. append나 insert라는 이름을 사용해야한다.

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

코드를 읽을 사람도 프로그래머이다.
전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다.

14. 문제 영역에서 가져온 이름을 사용하라

적절한 프로그래머 용어가 없다면 문제 영역에서 이름을 가져온다.

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

클래스 함수 이름 공간에 넣어 맥락을 부여한다.
마지막 수단으로 접두어를 붙여도 좋다.
예를 들어, firstName, lastName, street, houseNumber, city, state, zipcode라는 변수가 있으면 주소라는 것을 알아채지만, 어느 메서드가 state라는 변수 하나만 사용한다면 알아채기 쉽지않다.
addr이라는 접두어를 추가하면 맥락이 좀 더 분명해진다.
Address라는 클래스를 생성하면 더 좋다.

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

일반적으로는 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다. 이름에 불필요한 맥락을 추가하지 않도록 주의한다.

accountAddress와 customerAddress는 Address 클래스 인스턴스로는 좋은 이름이나 클래스 이름으로는 적합하지 못하다. Address는 클래스 이름으로 적합하다.

profile
Front-End Developer

0개의 댓글