[노개북 1기] TIL (2022.01.24)

yourjin·2022년 2월 26일

클린코드

read.log

목록 보기

5/37

TIL (2022.01.24)

DAY 4

🔖 오늘 읽은 범위 : 2장, 의미있는 이름(~p.32 자신의 기억력을 자랑하지 마라)

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

소프트웨어에서 이름은 어디나 쓰인다.
의도를 분명히 밝혀라
- 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다.
- 의도가 드러나는 이름을 사용하면 코드 이해와 변경이 쉬워진다.
그릇된 정보를 피하라
- 프로그래머는 코드에 그릇된 단서를 남겨서는 안 된다. 그릇된 단서는 코드 의미를 흐린다.
  - 나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안 된다.
  - 프로그래머에게 특수한 의미를 갖는 단어는 사용하지 않는다.
    (프로그래머에게 List라는 단어는 특수한 의미다.)
  - 서로 흡사한 이름을 사용하지 않도록 주의한다.
- 유사한 개념은 유사한 표기법을 사용한다. 이것도 정보다. 일관성이 떨어지는 표기법은 그릇된 정보다.
- 십중팔구 개발자는 (객체에 달린 상세한 주석이나 클래스가 제공하는 메서드 목록을 살펴보지 않은 채) 이름만 보고 객체를 선택한다.
  - 이름으로 그릇된 정보를 제공하는 진짜 끔찍한 예가 소문자 L이나 대문자 O 변수다.
    (...) 소문자 L은 숫자 1처럼 보이고 대문자 O는 숫자 0처럼 보인다.
의미 있게 구분하라
- 컴파일러나 인터프리터만 통과하려는 생각으로 코드를 구현하는 프로그래머는 스스로 문제를 일으킨다.
- 컴파일러를 통과할지라도 연속된 숫자를 덧붙이거나 불용어(noise word)를 추가하는 방식은 적절하지 못하다. 이름이 달라야 한다면 의미도 달라져야 한다.
  - 다른 클래스를 Productlnfo 혹은 ProductData라 부른다면 개념을 구분하지 않은 채 이름만 달리한 경우다. Info나 Data는 a, an, the 와 마찬가지로 의미가 불분명한 불용어다.
  - 불용어는 중복이다.
- 읽는 사람이 차이를 알도록 이름을 지어라.
발음하기 쉬운 이름을 사용하라
- 발음하기 쉬운 이름은 중요하다. 프로그래밍은 사회 활동이기 때문이다.
검색하기 쉬운 이름을 사용하라
- 문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다는 문제점이 있다.
- 이름 길이는 범위 크기에 비례해야 한다.
인코딩을 피하라
- 클래스와 함수는 접두어가 필요 없을 정도로 작아야 마땅하다.
자신의 기억력을 자랑하지 마라
- 똑똑한 프로그래머와 전문가 프로그래머 사이에서 나타나는 차이점 하나만 들자면, 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다. 전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다.

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

앞서 1장에서 ‘깨끗한 코드는 잘 쓴 글과 같다’라는 시각에 연장선에 있는 부분인 것 같다. 이름은 코드 어디에나 쓰이기 때문에 깨끗한 코드를 쓰기 위해서 더욱 중요하다. 잘 쓴 글(깨끗한 코드)은 잘 정제된 단어(의미 있는 이름)를 사용한다.
Info, Data와 같은 단어가 의미가 불분명한 불용어라는 사실은 이해되지만, 막상 “그럼 이 부분을 어떤 단어로 대체하면 좋을까?”라는 질문에 대한 답을 하기가 참 어려운 것 같다. 이럴 때 나는 보통 아래 내용들을 고려해본다.
- 뒤에 오는 불용어는 대체로 삭제한다. 뒤에 오는 경우는 보통 부가적인 의미로 사용되어 없애더라도 의미가 통하기 때문이다.
- 앞에 오는 불용어는 삭제할 수 없는 경우 그대로 두기도 한다. 데이터의 종류와 관계 없이 추출하는 기능을 모아 놓은 ‘데이터 추출’ 클래스를 만들고 싶은 경우를 예로 들 수 있다. 어떤 내용을 추출하는 지 한정하기 어렵고, ‘데이터’라는 말 없이 ‘추출’이라는 단어만 사용하면 정보가 부족해진다.
잘 지은 이름 하나가 여러 주석 안 부럽다!