※ 본 글은 인사이트에서 출간한 로버트 C. 마틴 저자의 『Clean Code(클린 코드) 애자일 소프트웨어 장인 정신』 책을 읽고 작성하였습니다.

🚦 2장. 의미있는 이름

🚀 소프트웨어에서 이름은 어디나 쓰임

• 변수, 함수, 인자, 클래스, 패키지, 소스파일, 심지어 소스파일이 담긴 디렉토리 등등
   → 이렇게나 많이 사용하므로 이름을 잘 지으면 여러모로 편리함.

• 이름을 잘 짓는 간단한 규칙에 대한 학습을 시-작!!
  
  

🚀 의도를 분명히 밝혀라

• 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많음.
• 이름을 주의 깊게 살펴 더 나은 이름이 떠오르면 개선할 것.
• 이름을 잘 지으면 코드를 읽는 사람이 좀 더 행복해 질 수 있음.
• 변수/함수/클래스의 이름은 존재 이유/수행 기능/사용 방법과 같은 질문에 답할 수 있어야 함.
  
  

🚀 그릇된 정보를 피하라

• 프로그래머는 코드에 그릇된 단서를 남겨서는 안됨
   → 그릇된 단서는 코드 의미를 흐림.
• 나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안됨. (e.g. list)
• 서로 흡사한 이름을 사용하지 않도록 주의할 것
• 유사한 개념은 유사한 표기법을 사용하고 이것도 정보에 해당됨.
• 일관성이 떨어지는 표기법은 그릇된 정보임.
  
  

🚀 의미 있게 구분하라

• 컴파일러나 인터프리터만 통과하려는 생각으로 코드를 구현하는 프로그래머는 스스로 문제를 일으킴.
• 동일한 범위 안에서 다른 두 개념에 같은 이름을 사용하지 못하기 때문에 한쪽 이름을 고치려다가 잘못 고치는 순간 컴파일이 불가능한 상황에 빠짐.
• 연속적인 숫자를 덧붙인 이름(a1, a2, …, aN)은 그릇된 정보를 제공하는 이름도 아니고, 아무런 정보를 제공하지 못하는 이름일 뿐, 저자 의도가 전혀 드러나지 않음.
  불용어를 추가한 이름 역시 아무런 정보도 제공하지 못함.
   → a나 the같은 접두사이더라도 의미가 분명히 다르다면 사용해도 무방.
• 읽는 사람이 차이를 알도록 이름을 붙여라
   → 나쁜 예시 : getctiveAcount(), getctiveAcounts(), getctiveAcountInfo()
  
  

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

• 두뇌에서 상당한 부분은 단어라는 개념만 전적으로 처리하고, 정의상으로 단어는 발음이 가능하므로, 발음하기 쉬운 이름을 선택하는 것이 좋음.
  
  

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

• 문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다는 문제점이 있음
• 짧은 숫자나 문자는 여러 군데에서 등장하므로 긴 이름이 짧은 이름보다 좋고, 검색하기 쉬운 이름이 상수보다 좋음.
• 한 문자만 사용하고 싶다면, 간단한 메서드에서 로컬 변수를 지정할 때 사용할 것.
• 이름 길이는 범위 크기에 비례해야 하며, 변수나 상수를 코드 여러 곳에서 사용한다면 검색하기 쉬운 이름이 바람직함.
  
  

🚀 인코딩을 피하라

• 이름에 인코딩할 정보는 매우 많으며, 유형이나 범위까지 인코딩에 넣으면 그만큼 해독이 어려워짐.
• 때로는 인코딩이 필요한 경우도 있음.
   → 인터페이스 클래스와 구현 클래스
  
  

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

• 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수 이름은 바람직하지 않음.
• 일반적으로 문제 영역이나 해법 영역에서 사용하지 않는 이름을 선택했기 때문에 생기는 문제.
• 루프에서 반복 횟수를 세는 변수는 문자 하나만 사용해도 괜찮음.
   → 소문자 L은 제외하며, 루프 범위가 아주 작고 다른 이름과 충돌하지 않을 경우에 한정.
• 똑똑한 프로그래머와 전문가 프로그래머 사이에서 나타나는 차이점 하나만 들자면, 전문가 프로그래머는 명료함이 최고라는 사실을 이해함.
   → 전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓음.
  
  

🚀 클래스 이름

• 클래스 이름과 객체 이름은 명사나 명사구가 적합함.
• 좋은 예 : Customer, WikiPage, Account, AddressParser
• 나쁜 예 : Manager, Processor, Data, Info 등과 같은 단어.
               → 동사는 아예 사용하지 않음.
  
  

🚀 메서드 이름

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

  • 좋은 예 : postPayment, deletePage, save 등
  • 접근자(Accessor), 변경자(Mutator), 조건자(Predicate)는 javabean 표준에 따라 값 앞에 get, set, is를 붙임.

• 생성자(Constructor)를 중복정의(overload)할 때는 정적 팩토리 메서드를 사용함.
   → 메서드는 인수를 설명하는 이름을 사용함.
  
  

🚀 기발한 이름은 피하라

• 이름이 너무 기발하면 기억할 사람만 그 이름을 기억함.
• 재미난 이름보다 명료한 이름을 선택하라.
• 의도를 분명하고 솔직하게 표현하라
  
  

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

• 추상적인 개념 하나에 단어 하나를 선택해 이를 고수하게 되면 어느 클래스에서 어느 이름을 썼는지 기억하기 어려움.
   → 예를 들어, 클래스마다 같은 메서드 이름을 사용하는 것.
• 이클립스, 인텔리제이 등과 같은 최신 IDE는 문맥에 맞는 단어를 제공함.

  • 예를 들어, 객체를 사용하면 그 객체가 제공하는 메서드 목록을 보여줌.
  • 하지만 목록은 보통 함수 이름과 매개변수만 보여줄 뿐 주석은 보여주지 않음.

• 따라서 메서드 이름은 독자적이고 일관적이어야 함.
• 일관성 있는 어휘는 코드를 사용할 프로그래머가 반갑게 여길 선물임.
  
  

🚀 말장난을 하지 마라

• 한 단어를 두 가지 목적으로 사용하지 말 것
• 여러 클래스에서 한 단어를 동일한 기능의 메서드에 사용하게 되더라도 그 메서드의 매개변수와 반환 값이 의미적으로 똑같다면 문제가 없음.
• 프로그래머는 코드를 최대한 이해하기 쉽게 짜야 함.
• 집중적인 탐구가 필요한 코드가 아니라 대충 훑어봐도 이해할 코드 작성이 목표임.
  
  

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

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

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

• 적절한 '프로그래머 용어'가 없다면 문제 영역에서 이름을 가져올 것.
• 그러면 코드를 보수하는 프로그래머가 분야 전문가에게 의미를 물어 파악할 수 있음.
• 우수한 프로그래머와 설계자라면 해법 영역과 문제 영역을 구분할 줄 알아야 함.
• 문제 영역 개념과 관련이 깊은 코드라면 문제 영역에서 이름을 가져와야 함
  
  

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

• 스스로 의미가 분명한 이름이 없지는 않지만 대다수의 이름은 그렇지 못함.
• 그래서 클래스, 함수, 이름 공간에 넣어 맥락을 부여함.
• 모든 방법이 실패하면 마지막 수단으로 접두어를 붙임.
  
  

🚀 불필요한 맥락을 없애라

• 고급 휘발유 충전소(Gas Station Deluxe) 라는 애플리케이션을 짠다고 가정.
• 모든 클래스 이름을 GSD로 시작하게 된다면 IDE에서 G를 입력하고 자동완성 키를 누르는 순간 모든 클래스를 열거하기 때문에 현명하지 못함.
• 일반적으로는 의미가 분명한 경우에 한해 짧은 이름이 긴 이름보다 좋음.
• accountAddress와 customerAddress는 Address 클래스의 인스턴스로는 좋은 이름이나, 클래스 이름으로 적합하지 못함.
  
  

🚀 마치면서

• 좋은 이름을 선택하려면 설명 능력이 뛰어나야 하고 문화적 배경이 같아야 함
• 좋은 이름을 선택하는 능력은 기술, 비즈니스, 관리 문제가 아닌 교육 문제임
• 사람들이 이름을 바꾸지 않으려는 이유 하나가 다른 개발자가 반대할까 두려워서임.
• 그러나 오히려 좋은 이름으로 바꿈으로써 코드 가독성이 높아짐.
• 다른 사람이 짠 코드를 손본다면 리팩터링 도구를 사용해 문제 해결 목적으로 이름을 개선하는 것이 좋음.
• 이것은 단기적인 효과는 물론 장기적인 이익도 보장함.