[노마드북클럽] 2장. 의미있는 이름

TIL (Today I Learned)

• 2022.02.20

오늘 읽은 범위

• 2장. 의미있는 이름

책에서 기억하고 싶은 내용을 써보세요.

• 의도를 분명히 밝혀라

- 문제는 코드의 단순성이 아니라 코드의 함축성이다. 다시 말해, 코드 맥락이 코드 자체에 명시적으로 드러나지 않는다.

- 단순히 이름만 고쳤는데도 함수가 하는 일을 이해하기 쉬워졌다. 바로 이것이 좋은 이름을 주는 위력이다.

• 그릇된 정보를 피하라

- 서로 흡사한 이름을 사용하지 않도록 주의한다. 유사한 개념은 유사한 표기법을 사용한다. 이것도 정보다. 일관성이 떨어지는표기법은 그릇된 정보다

• 의미 있게 구분하라

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

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

- 발음하기 어려운 이름은 토론하기도 어렵다. 바보처럼 들리기 쉽상이다 발음하기 쉬운 이름은 중요하다. 프로그래밍은 사회 활동이기 때문이다.

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

- 긴 이름이 짧은 이름보다 좋다. 검색하기 쉬운 이름이 상수보다 좋다.

- 개인적으로는 간단한 메서드에서 로컬 변수만 한 문자를 사용한다. 이름 길이는 범위 크기에 비례해야 한다.

• 인코딩을 피하라

- 헝가리식 표기법이나 기타 인코딩 방식이 오히려 방해가 될 뿐이다. 변수, 함수, 클래스 이름이나 타입을 바꾸기가 어려워지며, 읽기도 어려워진다. 독자를 오도할 가능성도 커진다.

• 멤버 변수 접두어

- 이제는 멤버 변수에 m_이라는 접두어를 붙일 필요도 없다. 클래스와 함수는 접두어가 필요없을 정도로 작아야 마땅하다. 또한 멤버 변수를 다른 색상으로 표시하거나 눈에 띄게 보여주는 IDE를 사용해야 마땅하다.

• 인터페이스 클래스와 구현 클래스

- 인터페이스 클래스 이름과 구현 클래스 이름 중 하나를 인코딩 해야한다면 구현클래스 이름을 택하겠다. ShapeFactoryImp나 심지어 CShapeFactory가 IShapeFactory보다 좋다.

자신의 기억력을 자랑하지 마라-전문가 프로그래머는 명료함이 최고라는 사실을 이해한다. 전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다.

- 독자가 코드를 읽으면서 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수 이름은 바람직하지 못하다.

- 클래스 이름과 객체 이름은 명사나 명사구가 적합하다. 동사는 사용하지 않는다.

- 메서드 이름은 동사나 동사구가 적합하다.

- 생성자를 중복정의할 때는 정적 팩토리 메서드를 사용한다. 메서드는 인수를 설명하는 이름을 사용한다. 예를들어, 다음 두 예제를 살펴보자.

     Complex fulcrumPoint = Complex.FromRealNumber(23.0);

위 코드가 아래 코드보다 좋다.

     Complex fulcrumPoint = new Complex(23.0);

생성자 사용을 제한하려면 해당 생성자를 private로 선언한다.

• 기발한 이름은 피하라

- 재미난 이름보다 명료한 이름을 선택하라.

• 한 개념에 한 단어를 사용하라

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

- 메서드 이름은 독자적이고 일관적이여야 한다. 그래야 주석을 뒤져보지 않고도 프로그래머가 올바른 메서드를 선택한다.

• 말장난을 하지 마라

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

- 프로그래머는 코드를 최대한 이해하기 쉽게 짜야한다. 집중적인 탐구가 필요한 코드가 아니라 대충 훑어봐도 이해할 코드 작성이 목표다. 의미를 해독할 책임이 독자에게 있는 논문 모델이 아니라 의도를 밝힐 책임이 있는 저자에게 있는 잡지 모델이 바람직하다.

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

- 코드를 읽을 사람도 프로그래머라는 사실을 명심한다. 그러므로 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다.

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

- 우수한 프로그래머와 설계자라면 해법 영역과 문제 영역을 구분할 줄 알아야 한다. 문제 영역 개념과 관련이 깊은 코드라면 문제 영역에서 이름을 가져와야 한다.

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

• 의미 있는 맥락을 추가하라
• 불필요한 맥락을 없애라

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

• 마치면서

- 좋은 이름을 선택하려면 설명 능력이 뛰어나야 하고 문화적인 배경이 같아야 한다.

- 우리들 대다수는 자신이 짠 클래스 이름과 매서드 이름을 모두 암기하지 못한다.

 

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

• 역시 바이블 같은 책이다. 나는 개발할때 주석이 제일 중요한 줄 알았다. 그래서 변수 하나하나에도 주석을 달곤 했는데 주석을 다는 것 보다 변수의 이름이나 메소드의 이름을 잘 표현하면 주석을 대신 할 수 있다는 것을 배웠다. 

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

• 의미 있는 맥락을 추가하라 부분에서 설명하는 이야기가 특정한 상황에서 변수들에 값을 담을 때 의미가 담긴 이름의 메서드를 만들어 표현함으로써 해당 상황을 설명한다? 라고 해석했는데 잘 모르겠다.