[TIL] 클린코드(Clean Code) - 2장. 의미 있는 이름

📆 TIL (Today I Learned) 날짜

2022.02.20

📚 오늘 읽은 범위

2장. 의미 있는 이름

📝 책에서 기억하고 싶은 내용

• 의도를 분명히 밝혀라. 변수나 함수 그리고 클래스 이름은 다음과 같은 굵직한 질문에 모두 답해야 한다. 변수(혹은 함수나 클래스)의 존재 이유는? 수행 기능은? 사용 방법은? 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다. (p.22)
• 그릇된 정보를 피하라. 프로그래머는 코드에 그릇된 단서를 남겨서는 안 된다. 그릇된 단서는 코드 의미를 흐린다. 나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안 된다. 서로 흡사한 이름을 사용하지 않도록 주의한다. 유사한 개념은 유사한 표기법을 사용한다. 이것도 정보다. 일관성이 떨어지는 표기법은 그릇된 정보다. (p.24)
• 의미 있게 구분하라. 읽는 사람이 차이를 알도록 이름을 지어라. (p.27)
• 발음하기 쉬운 이름을 사용하라. 발음하기 쉬운 이름은 중요하다. 프로그래밍은 사회 활동이기 때문이다. (p.27)
• 검색하기 쉬운 이름을 사용하라. 문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다는 문제점이 있다. (p.28)
• 인코딩을 피하라. 문제 해결에 집중하는 개발자에게 인코딩은 불필요한 정신적 부담이다. 인코딩한 이름은 거의가 발음하기 어려우며 오타가 생기기도 쉽다. (p.29)
• 자신의 기억력을 자랑하지 마라. 똑똑한 프로그래머와 전문가 프로그래머 사이에서 나타나는 차이점 하나만 들자면, 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다. 전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다. (p.31)
• 클래스 이름과 객체 이름은 명사나 명사구가 적합하다. (p.32)
• 메서드 이름은 동사나 동사구가 적합하다. (p.32)
• 프로그래머는 코드를 최대한 이해하기 쉽게 짜야 한다. 집중적인 탐구가 필요한 코드가 아니라 대충 훑어봐도 이해할 코드 작성이 목표다. 의미를 해독할 책임이 독자에게 있는 논문 모델이 아니라 의도를 밝힐 책임이 저자에게 있는 잡지 모델이 바람직하다. (p.34)
• 우수한 프로그래머와 설계자라면 해법 영역과 문제 영역을 구분할 줄 알아야 한다. 문제 영역 개념과 관련이 깊은 코드라면 문제 영역에서 이름을 가져와야 한다. (p.35)

😀 오늘 읽은 소감 및 떠오르는 생각

• 한글 이름은 나름 잘 지을 수 있을거라 생각하는데 대부분의 모든(?) 프로그래밍 언어는 영어로 작성해야 하기 때문에 영어를 잘 해야 이름도 잘 지을 수 있을거란 생각이 들었다. 내 영어 실력은 언제쯤 늘까? 실제로 지난 프로젝트에서는 잘못 알고있던 영단어가 있어서 함수 이름을 잘못 만든 경우도 있었다. 나중에 스스로 알고나서 어찌나 부끄러웠던지.. 여기저기서 많이 사용되던거라 결국 수정도 할 수 없어 그냥 냅두었다..😥

🤔 궁금한 내용 및 잘 이해되지 않는 내용

• 인코딩(encoding) : 암호화 하다. 부호화 하다. 본문에서 의미하는 인코딩이란 긴 단어를 짧게 변환시킨 것을 의미하는 것 같다. 예로 COMMON 이라는 단어를 CMM 으로 축약 시켰다던지 UPDATE 를 UPD 로 축약 시켰다던지 등등.. 단어를 이렇게 축약하는 표준도 국내에 있었던 것 같은데 실제 경험해본자로써 후기를 얘기해보자면 진짜 읽을 수가 없는 단어가 많아져서 이게 도대체 무슨 암호문인가 싶었던적이 있다. 특히 데이터베이스 테이블명이 그런 경우가 많은데 따로 약어집이 필요할 정도로 읽기도 힘들뿐만 아니라 외우기도 힘들어서 항상 어디 기록해두고 사용해야 했었다.