TIL (Today I Learned)

2022.02.20

오늘 읽은 범위

2장. 의미 있는 이름

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

• 그릇된 정보를 피하라

  1. 나름대로 널리 쓰이는 의미가 있는 단어는 다른 의미로 사용해서 안된다.

  2. 서로 흡사한 이름을 사용하지 않도록 주의한다.

  3. 유사한 개념은 유사한 표기법을 사용한다.

  4. 이름으로 그릇된 정보를 주는 가장 끔찍한 예는 소문자 l과 대문자 O이다. 이는 0,1 처럼 보인다.

• 의미 있게 구분하라

  1. 연속된 숫자(a1,a2...aN)를 덧붙이거나 불용어(Info, Data, a, an, the)를 추가하는 것은 적절하지 못하다.

  2. 변수 이름에 variable, 표 이름에 table 단어를 사용하는 것도 마찬가지다 NameString이 Name보다 뭐가 나은가?

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

  1. 사람들은 단어에 익숙하다. 그리고 정의상 단어는 발음이 가능하다. 말을 처리하려고 발달한 두뇌를 이용하지 않는다면 안타까운 손해이다.

  2. 발음하기 어려운 이름은 토론하기도 어렵다. '여기 bcr3ntpszq int가 보이십니까?' 바보처럼 보이기 쉽상이다. 발음하기 쉬운 이름은 중요하다. 프로그래밍은 사회 활동이기 때문이다.

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

  문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다는 문제점이 있다. (s보다 sum이 5보다 WORK_DAYS_PER_WEEK가 검색하기 쉽다.)

• 인코딩을 피하라

  굳이 부담을 더하지 않아도 인코딩할 정보는 아주 많다. 유형이나 범위, 정보까지 인코딩에 넣으면 그만큼 이름을 해독하기 어려워진다.

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

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

  2. 똑똑한 프로그래머와 전문가 프로그래머 사이에 나타나는 차이점을 하나만 들자면, 전문가 프로그래머는 명료함이 최고하는 사실을 이해한다. 전문가 프로그래머는 자신의 능력을 좋은 방향으로 활용해 남들이 이해하는 코드를 내놓는다.

• 클래스 이름 - 클래스 이름과 객체 이름은 명사나 명사구가 적합하다.

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

• 기발한 이름은 피하라

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

  2. 특정 문화에서만 사용하는 표현은 피하라(kill() 대신 whack(), abort()대신 eatMyShort()이라 쓰는것은 잘못된 예이다.) 의도를 분명하고 솔직하게 표현하라.

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

  추상적인 개념에 단어 하나를 선택해 이를 고수하라 똑같은 메서드를 클래스마다 (fetch, retrieve, get)으로 제각각 부르면 혼란스럽다.

• 말장난을 피하라

  한 단어를 두가지 목적으로 사용하지 마라.다른 개념에 같은 단어를 사용한다면 그것은 말장난에 불과하다. (ex: 지금까지 구현한 모든 add 메서드가 기존 값을 더하는 것이라면 새로 집합에 값 하나를 추가하는 메서드를 만들때 add 대신 insert나 append를 사용하라)

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

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

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

  적절한 프로그래머 용어가 없다면 문제적 영역에서 이름을 가져온다. 그러면 코드를 보수하는 프로그래머가 분야 전문가에게 의미를 물어 파악할 수 있다.

• 의미 있는 맥락을 추가하라

  모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다. (주소와 관련된 변수에 addr을 붙이기 : addrState, addrFirstName, addrLastName) -> 물론 Address라는 클래스를 만들어 묶는게 더 좋음

• 불필요한 맥락을 없애라

  1. 고급 휘발류(gas station deluxe)를 관리하는 프로그램을 만든다고 해서 모든 변수에 GSD를 붙이는 것은 바람직하지 못하다. 검색시 G를 입력하면 IDE는 모든 클래스를 열거한다. IDE는 개발자를 지원하는 도구이다. IDE를 방해할 이유는 없다.

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

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

• 프로그램을 만들다보다 항상 어떤 이름을 지어야 하는가에 막힌다. 지금까지 나는 너무 긴 단어를 축약하여 이름을 짓는 경우가 많았다(ex: dateCalculator -> D_cal) 부족한 정보는 주석을 통해 보충하면 된다고 생각했었다. 하지만 이 책의 2장을 읽으면서 좋은 이름이란 무엇인가 고민했다. 그 결과 나는 좋은 이름이란 주석이 없어도 모두가 이해할 수 있는 이름이라는 것을 깨달았다. 이 책은 이름을 지을 때 간단하면서도 그릇된 정보를 주지 않으면서 명료하고 의미가 분명한 이름을 줄 것을 강조한다. 앞으로 이름을 지을 때 다음 조건들을 한번씩 생각해보며 명료한 이름을 짓는 습관을 들여야겠다.

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