📅 TIL (Today I Learned): 2024.01.28
📋 오늘 읽은 범위: 2. 의미 있는 이름
😎 책에서 기억하고 싶은 내용을 써보세요.
함수, 인수, 클래스, 패키지, 파일, 소스 파일 디렉토리, jar 파일, war 파일 등등에 사용되는 이름이라 규칙을 지키며 작성하면 좋다. 아래 요약 내용은 많은 규칙 중 제일 와닿은 것들이다.
의도를 분명히 밝혀라
코드의 단순성 < 코드의 함축성
함수명이나 변수명에 코드 맥락이 드러나도록 작성하게 하기
그릇된 정보를 피하라
- 나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하면 안 된다
- 서로 흡사한 이름을 사용하지 않도록 주의한다
의미 있게 구분하라
- 연속적인 숫자 X
- 불용어 X (ex. info, data, variable)
읽는 사람이 차이를 알도록 이름을 지어라
검색하기 쉬운 이름을 사용하라
간단한 메서드에서 로컬 변수만 한 문자를 사용한다.
이름 길이는 범위 크기에 비례해야 한다.
이름을 의미 있게 지으면 함수가 길어진다.
-> 그래도 검색하기 쉽다... (이거 인정)
말장난을 하지 마라
(말장난이라고 되어 있지만 예시된 내용은 달랐다.)
'한 개념에 한 단어를 사용하라'라는 규칙을 따랐더니, 여러 클래스에 add라는 메서드가 생겼다
-> 같은 맥락이 아닌데도 '일관성'을 고려해 add라는 단어를 선택한다
-> 이러면 일관성은 지켜도 이해하기 어렵다
🥺 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.
평소 개발할 때 변수를 정하는 데에 시간이 가장 오래 걸린다.
HttpMethod가 GET인 메서드를 사용할 때 select, find, get 등을 사용할 수 있다. 따로 규칙이 정해져 있지 않은 상황에서는 다른 사람들이 어떤 단어를 가장 많이 사용했는지 확인하고 정하게 되는데, 내가 작성한 내부 성격이 묘하게 그 단어와 다를 때가 있다. 이때 고민이 되고 이걸 어떻게 해결해야 하나 고민만 하다가 시간이 더 오래 걸린다.
이 많은 규칙을 다 적용하기가 쉽지는 않지만 개발할 때마다 체크하려고 한다.
처음에는 정말 많은 시간이 걸리겠지만 내가 책을 펴본 만큼 코드는 읽기 쉬워지고 좋은 코드가 될 것이고, 나중엔 굳이 책을 펴지 않더라도 그 규칙에 맞춰 작성하는 개발자가 될 것이다.
🤔 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
검색하기 쉬운 이름을 사용하라는 부분에서 e, 7 이런 것보다는 WORK_DAYS_PER_WEEK 라는 단어가 더 찾기 쉽다는 부분을 읽었다. 그 부분에 대해서는 전적으로 동의한다. 이 변수가 어디서 사용되는지 IDE를 통해 찾을 수도 있겠지만 보통은 command + F로 찾기도 하기 때문이다.
그러나 이런 단어를 사용할수록 코드가 길어져 오히려 가독성을 해치진 않을까 걱정도 된다.
책의 내용에서는 정확한 의미가 들어간 이름을 추천했지만, 그 코드를 읽을 때 코드가 한 눈에 들어오지 않아 보이기도 했다.
적절한 길이의 변수를 작성하도록 노력해볼 것이다. 그러나 쉽지 않은 길이다...
🫣 이 책 왜 읽으시나요?
슬랙에 인삿말을 남기며 이유를 적었다.
읽은 척만 한 내 자신이 싫어서...😔 진짜 읽고 코드에 녹여내는 게 내 꿈이다.
