TIL (Today I Learned)

22.02.20

오늘 읽은 범위

2장 의미 있는 이름

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

• 의도를 분명히 밝히라 p22

  좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다. 

  Int d; // 경과 시간(단위: 날짜)

  이름 d는 아무 의미도 드러나지 않는다. 경과 시간이나 날짜라는 느낌이 안든다. `

  Int elapsedTimeDays` `

  Int daysSinceCreation` 

  의도가 드러나는 이름을 사용하면 코드 이해와 변경이 쉬워진다. 

  for(init[] x : theList)

  if(x[0]==4){

  list1.add(x);

  return list1;

  }

  코드가 하는 일을 짐작하기 어렵다. 

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

  위 코드는 암암리에 독자가 다음과 같은 정보를 안다고 가정한다.

  1. theList에 무엇이 들어있는가

  2. theList에서 0번째 값이 어째서 중요한가

  3. 값 4는 무슨 의미인가

  4. 함수가 반환하는 리스트 lists1을 어떻게 사용하는가 

  • p26 의미있게 구분하라

  불용어를 추가한 이름 역시 아무런 정보도 제공하지 못한다. Product라는 클래스가 있다고 가정하자.

  다른 클래스를 ProductInfo 혹은 ProductData라고 부른다면 개념을 구분하지 않은 채 이름만 달리한 경우다. 

  • p27 명확한 관례가 없다면 변수 moneyAccount는 money와 구분이 안된다. customerInfo는 customer와 accountData는 account와 theMessage는 message와 구분이 안된다. 읽는 사람이 차이를 알도록 이름을 지어라. 

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

  문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다는 문제점이 있다.

  MAX_CLASSES_PER_STUDENT는 grep으로 찾기가 쉽지만 숫자 7은 은근히 까다롭다. 7이 들어가는 파일 이름이나 수식이 모두 검색되기 때문이다. 

  for(int j=0; j <34; j++) {

  s + s(t[j]*4)/5;

  }

  (여기서 5는 WORKS_DAYS_PER_WEEK으로 대체 가능하다.)

  그냥 5를 사용한다면 5가 들어가는 이름을 모두 찾은 후 의미를 분석해서 원하는 상수를 가려내야 하리라. 

  • p32

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

    Customer, WikiPage, Account, AddressParser가 좋은 예이다. 

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

    postPayment, deletePage, save등이 좋은 예다.

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

오늘은 의미 있는 이름에 대한 내용을 읽었다. 사실 클린코드를 하면 좋다는 것을 알면서도 깊게 고민하지 않은 것처럼 의미 있는 이름 짓기도 마찬가지로 좋은 이름을 지어야 한다는 것에 동의하면서 왜 중요한 지, 안좋은 이름을 지었을 때 어떤 비용이 드는 지에 대한 고민을 깊게 해보지 않았던 것 같다.

실제로 코드리뷰에서 변수의 이름에 대한 코멘트가 나왔을 때 뭘이런걸 다 라는 생각을 속으로 해본적도 있다. 하지만 이 장을 보며 내가 얼마나 무지 했는 지, 의미 있는 이름이 얼마나 중요한 지를 깨달을 수 있었다. 좋은 이름을 짓는 것은 단기적으로 시간이 들지라도 장기적으로는 큰 비용을 절감 할 수 있다. 내가 지은 불분명한 변수는 그 당시에는 명료할 지라도 시간이 지난 후 다시 봤을 때 내가 만든 코드라 할지라도 헷갈리게 만든다. 그렇다면 남이 볼 때는 얼마나 더 불분명 하겠는가.

이름을 지을 때는 그 자체로 의미를 제공하는 지에 대해 깊은 고민해봐야 한다. 단순히 이름을 달리 하기 위해 그 자체로 의미를 제공하지 못하는 Data, List 같은 것으로 변수를 할당 해서는 안된다.

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

• // 르블랑의 법칙? (LeBlanc's Law states) - "Later equals never" is used in the context of software development, but may be applied more broadly to other areas. The law is attributed to Dave LeBlanc.