노마드코더 북클럽 클린코드 TIL 두번째

2022년 4월 24일 TIL

오늘 TIL 3줄 요약

이름에 의미가 명확하지 않은 부분은 덜어내자.
발음하기 쉬운 이름을 사용해라.
코드를 읽을 사람이 프로그래머임을 명심하고 이름을 짓자.

오늘 읽은 범위

2장 의미있는 이름

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

컴파일러나 인터프리터만 통과하려는 생각으로 코드를 구현하는 프로그래머는 스스로 문제를 일으킨다. (p.60)
불용어를 추가한 이름 역시 아무런 정보도 제공하지 못한다. Product라는 클래스가 있다고 가정하자. 다른 클래스를 ProductInfo 혹은 ProductData라 부른다면 개념을 구분하지 않은 채 이름만 달리한 경우다. Info나 Data는 a, an, the와 마찬가지로 의미가 불분명한 불용어다. (p.61)
불용어는 중복이다. 변수 이름에 variable이라는 단어는 단연코 금물이다. 표 이름에 table이라는 단어도 마찬가지다. NameString이 Name보다 뭐가 나은가? Name이 부동소수가 될 가능성이 있던가? 그렇다면 앞서 언급한 "그릇된 정보를 피하라" 규칙을 위반한다. (p.61)
발음하기 쉬운 이름을 사용하라 (p.62)
검색하기 쉬운 이름을 사용하라 (p.63)
문제 해결에 집중하는 개발자에게 인코딩은 불필요한 정신적 부담이다. 인코딩한 이름은 거의가 발음하기 어려우며 오타가 생기기도 쉽다. (p.64)
특정 문화에서만 사용하는 농담은 피하는 편이 좋다. 의도를 분명하고 솔직하게 표현하라. (p.68)
프로그래머는 코드를 최대한 이해하기 쉽게 짜야 한다. 집중적인 탐구가 필요한 코드가 아니라 대충 훑어봐도 이해할 코드 작성이 목표다. 의미를 해독할 책임이 독자에게 있는 논문 모델이 아니라 의도를 밝힐 책임이 저자에게 있는 잡지 모델이 바람직하다. (p.69)
코드를 읽을 사람도 프로그래머라는 사실을 명심힌다. 그러므로 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다. (p.69)

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

새로운 컨텐츠를 개발할 때, 처음에 아무런 의미 없는 이름(Potato 처럼..)으로 작업을 시작한 뒤에 나중에 기획에서 테이블에 대한 부분이 정리 됐을 때 기획서에 명시된 용어를 그대로 반영하는 식으로 작업을 했던 경우가 있었다. 이름을 고민하는 시간을 줄이고자 했던 부분도 있었지만 무엇보다 기획 문서와 코드간에 용어를 통일하고자 생각했던 것이다. 하지만 프로그래머가 기존 구현된 내용을 파악할 때 기획서를 찾아보기 보다는 코드를 분석하는 경우가 더 많다는 생각이 들었다. 심지어 기획서는 처음 기획 이후에 기능이 추가되더라도 문서가 갱신되지 않는 경우도 많다. 코드를 읽을 사람도 프로그래머.. 명심하자.
언리얼 코딩 스탠다드를 따르다보면 변수나 함수는 모두 PascalCase로 통일 시키지만 클래스의 이름은 AActor를 상속으면 A를 앞에 붙인다던가, Interface는 I를 붙인다던가(블루프린트 노출하는 Interface는 U가 붙은 클래스도 함께..), 그 외에는 U를 붙인다던가, 슬레이트는 S를 붙인다던가.. 하는 본문에서 얘기한 인코딩이 꼭 붙어야한다. 하지만 이 부분은 UHT에서 코드를 자동 생성할 때 사용되는 부분이라 코드를 읽을 프로그래머를 위한게 아니라 코드를 읽을 UHT를 위한 부분이기도 하니 어쩔수 없는 부분 아닐까..?
최근에 작업하면서 배열에는 List, 맵에는 Map 을 변수이름에 넣으면서 작성한 적이 있는데, 아무래도 List인 경우와 Map인 경우에 호출하는 메서드의 이름이 같지 않기 때문에 그렇게 인코딩을 넣었던 것인데, 실제 사용할 때는 동일한 형태로 사용되는 경우도 있기도 하고, Container라는 판단은 인코딩이 없어서 알 수 있으니 인코딩이 필요한 부분은 아닌것 같다. 제거해야겠다.
코드 리뷰를 진행하던 팀에 있을 때, 변수 이름을 얘기하면서 리뷰를 진행하기도 하기 때문에 발음하기 쉬운 이름을 사용하는 것은 의외로 중요한 부분이아닐까 싶다. 본문에서 말했던 genymdhms를 리뷰하는 상황에 처한다면 그 시점에 리뷰는 끝나지 않을까..