[Clean Code] 클린코드 책읽기 2장 - 의미 있는 이름

이하영·2023년 6월 15일
0

CleanCode 읽기

목록 보기
3/4
post-thumbnail

로버트 C. 마틴의 Clean Code 라는 책을 읽고, 학습하고 정리하는 글 입니다.


Clean Code 클린 코드 애자일 소프트웨어 장인 정신

  • 읽은 날짜 : 23.06.15 ~ 23.06.20
  • 읽은 범위 : 2장 의미 있는 이름
  • 주요 키워드 :
    이름 명명규칙

✅ 2장 의미 있는 이름

  • 소프트웨어에서 이름은 어디나 쓰인다. 이름을 잘 지으면 여러모로 편하다.
  • 이 장에서 소개한 규칙을 적용하여 코드 가독성이 높아지는지 살펴보라.
  • 다른 사람이 짠 코드를 손본다면 리팩토링 도구를 사용해 이름을 개선하라. 단기적인 효과는 물론 장기적인 이익도 보장한다.

✍ 이름을 잘 짓는 간단한 규칙

- 의도를 분명히 밝혀라

  • 이름을 지을 때 생각해봐야 할 질문
    • 변수(혹은 함수나 클래스)의 존재 이유는?
    • 수행 기능은?
    • 사용 방법은?
  • 주석 없이도 의도/의미가 드러나는 이름
    → 코드 이해와 변경이 쉬워진다.

- 그릇된 정보를 피하라

  • 코드의 그릇된 단서를 남기면 코드 의미를 흐린다.
  • 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하면 안된다.
    (예 : accountList, hp 등)
  • 서로 흡사한 이름을 사용하지 않도록 주의한다.
  • 저자는 이름으로 그릇된 정보를 제공하는 예시로 소문자 L과 대문자 O를 들었다.
    글꼴에 따라 소문자 L은 1로, 대문자 O는 숫자 0으로 보일 수 있다.
    글꼴을 바꿔 확인해야하는 일거리를 만들 필요가 없다.

- 의미 있게 구분하라

  • 컴파일러를 통과할지라도 연속된 숫자를 덧붙이거나 불용어를 추가하는 방식은 적절하지 못하다.
    • 연속적인 숫자를 덧붙인 이름(a1, a2, ...)은 아무런 정보를 제공하지 못하고, 의도가 전혀 드러나지 않는다.
    • 불용어는 중복이다. / 불용어를 추가한 이름도 아무런 정보를 제공하지 못한다.
      • 의미가 분명히 다르다면 사용해도 무방하다.
      • 변수 이름에 variable은 금물
      • 표 이름에 table도 금물
  • 읽는 사람이 차이를 알도록 이름을 지어라.

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

  • 발음하기 어려운 이름은 토론하기 어렵다.
  • 프로그래밍은 사회 활동이기 때문에 발음하기 쉬운 이름은 중요하다.

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

  • 문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다는 문제점이 있다.
    • 상수에 문제/버그가 있을 시에 검색으로 찾을 수 없다.

- 인코딩을 피하라

  • 인코딩한 이름은 거의 발음하기 어렵고 오타가 생기기 쉽다.
  • 헝가리식 표기법
    • 과거에는 컴파일러가 타음을 점검하지 않았으므로 프로그래머에게 타입을 기억할 단서가 필요했다. 하지만 요즘에는 컴파일러가 타입을 기억하고 강제한다.
  • 멤버 변수 접두어
    • 이제는 멤버 변수에 m_이라는 접두어를 붙일 필요가 없다.
      • IDE에서는 멤버 변수를 다른 색상으로 표시하거나 눈에 띄게 보여준다.

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

  • 자신만 아는 이름을 사용하거나 문자 하나만을 사용하는 이름은 바람직하지 못하다.

- 클래스 이름

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

- 메소드 이름

  • 메서드 이름은 동사나 동사구가 적합하다.
  • 생성자를 중복 정의할 때는 정적 팩토리 메소드를 사용한다.
    • 생성자 사용을 제한하려면 해당 생성자를 private로 선언한다.

- 기발한 이름은 피하라

  • 재미난 이름보다 명료한 이름을 선택하고, 의도를 분명하고 솔직하게 표현해야 한다.

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

  • 추상적인 개념 하나에 단어 하나를 사용한다.
  • 메소드 이름은 독자적이로 일관적이어야 한다.

- 말장난을 하지 마라

  • 다른 개념에 같은 단어를 사용한다면 그것은 말장난에 불과하다.

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

  • 모든 이름은 문제 영역에서 가져오는 정책은 현명하지 못하다. 동료들이 매번 의미를 물어야 하기 때문이다.
  • 기술 개념에는 기술 이름이 가장 적합한 선택이다.

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

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

- 의미 있게 맥락을 추가하라

  • 클래스, 함수, 이름 공간에 맥락을 부여한다.
  • 예 :
    firstName, lastName, street, state, zipcode 라는 변수가 있을 때는 주소라는 사실을 알아챌 수 있다. 하지만 state 변수가 하나 있을 때에는 주소의 일부라는 사실을 알아채기 힘들다.
    이럴 때, addr라는 접두어를 추가해서 사용하면 맥락이 더 분명해진다.

- 불필요한 맥락을 없애라

  • 의미가 분명한 경우에 한해서, 짧은 이름이 긴 이름보다 좋다.
  • 이름에 불필요한 맥락을 추가하지 않도록 주의해야 한다.


💬 느낀점은..

이번 장을 읽으면서 이름을 잘 짓는 것도 코드의 가독성과 효율성에 영향을 준다는 것을 알게 되었다.
지금까지는 변수나 클래스나 메소드 이름을 지을 때 크게 신경을 안 썼는데, 앞으로는 다른 사람들도 이해할 수 있고 이름만 봐도 의미/기능을 예상할 수 있도록 해야겠다.
어떻게 보면 클린 코드의 제일 기본인 것 같다.

profile
안녕하세요, 웹 개발자 이하영입니다!

0개의 댓글