개발자 99% 커뮤니티에서 수다 떨어요!
TIL (Today I Learned)
// 2022.02.20
오늘 읽은 범위
// 2장. 의미 있는 이름
책에서 기억하고 싶은 내용을 써보세요.
<이름을 잘짓는 규칙>
1. 의도를 분명히 밝혀라
- 존재이유, 수행기능, 사용방법 : 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말
- 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 많다
(1장에서도 비슷한 뉘앙스의 얘기가 있었는데, 결국 이 책의 핵심이 이 문장인것 같다)
- 코드의 목적을 직관적으로 파악하기 어려운 이유는 단순성보다는 "함축성"(맥락)이 더 중요하다
2. 그릇된 정보를 피해라
- 약어를 사용하지 않는다 : 코드를 보게되는 다른 사람에게 그릇된 정보를 제공
- 유사한 개념은 유사한 표기법을 사용한다 : 일관성이 떨어지면 그릇된 정보다
- 특히 소문자 l과 대문자 O는 반드시 피해야 한다
3 의미있게 구분하라
- 동일한 범위 안에 다른 두 개념의 이름을 사용하지 않는다
- 연속된 숫자를 붙이거나, 불용어를 추가하는 방식은 적절하지 않는다 : 아무런 정보를 제공하지 않는다
4. 검색하기 쉬운 이름을 사용하라
- 문자 하나를 사용하는 이름은 눈에 쉽게 띄지도 않고, 검색이 용이하지 못하다
(이 맥락으로 e를 사용하는 것은 좋지 않다 / 루프에서 반복횟수를 세는i,j,k는 괜찮다. 단, 루프 범위가 작고 다른 이름과 충돌하지 않을때에 한해)
- 짧은 이름보다 긴 이름이 좋다 : 검색하기 쉬움
5. 자신의 기억력을 자랑하지 마라
- 코드를 읽는 사람이 변수 이름을 변환해야 한다면 바람직하지 못한 것이다
- 클래스 이름은 명사구가 적합하다
- 메써드 이름은 동사구가 적합하다
6. 한 개념에 한 단어를 사용하라
- 다만, 맥락을 고려해야 한다 : 매개변수와 반환값이 의미적으로 같다면 문제 없지만 일관성을 고려해 같은 단어를 쓰면 안된다
ex : 기존값을 더해서 새로운 값을 만드는 메써드를 add라고 지음
집합에 값 하나를 추가하는 메써더는 새로 만드려면 맥락이 다름 => append나 insert가 좋음
7. 해법영역이나 문제영역에서 가져온 이름을 사용하라
- 코드를 읽을 사람도 결국 프로그래머이다 : 적당한 전문용은 사용해도 된다
- 적절한 프로그래머 용어가 없다면 "문제"를 이름으로 삼는다 : 문제영역과 해법영역은 구분되어야 한다
8. 의미있는 맥락을 추가해라
- 위의 모든 방법들이 실패하면 접두어를 붙인다 : 통일성을 주어 맥락을 파악할 수 있음
결론
- 좋은 이름을 선택하려면 설명능력이 뛰어나야 하고 문화적인 배경이 같아야 한다
- 이름을 바꾸지 않으려는 이유는 다른 개발자가 반대할까 두려워서이다
- 자신이 짠 코드는 모두 암기할 수 없다. 따라서, 암기는 IDE에게 맡기고 잘읽히는 코드를 만드는데 집중해야 한다
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
의도를 분명히 밝혀라 - 팀원들이 리뷰하기 좋으라고 주석을 풍부하게 달곤 했는데, 그것보다는 명확하게 이름을 명시해서 맥락을 이해할수 있게 해주는 것이 더 좋은 방법이라고 깨달았다
검색하기 쉬운 이름을 사용해라 - 함수에 event 파라미터를 넘길때 습관적으로 e를, error 파라미터를 넘길때 err를 사용했는데 지금까지는 코드가 복잡하지 않아 문제가 안됐지만 장기적으로는 좋지 않은 습관이라는 것을 깨달았다
자신의 기억력을 자랑하지 마라 - 예전에 인터넷에서 코딩 잘하는 비법 같은 걸 검색하보면서 동사구를 활용해 어떤 동작을 하는지 명확하게 밝히는것이 좋다는 것을 본 기억이 있어서 그걸 적용해본 프로젝트가 있었다. 그게 이 내용이라는 것이 떠오르며 무척 반가웠다. 다시 한번 그 코드를 들여다보니 역시나 맥락의 파악이 잘 되었던것 같다
(단순한 청기백기 게임인데 딱 8개의 함수로만 이루어져있다)
generate_random_number
generate_mission
clickButton
calculate_score
proceed_progressBar
clickStart
clickStop
clickReset
얼마전에 한 커뮤니티에서 ★을 1개부터 5개까지 화면에 찍는 작업을 반복문으로 짠 코드와 하드코딩한 코드를 놓고 누가 더 잘하는 개발자이냐 라는 글을 본 기억이 있다. 개발자가 아닌 사람들이 대다수일테니 갑론을박이 많았으나 대다수는 "이정도 작업이면 하드코딩이 낫지 않겠냐" 였다. 개발자인 나는 격렬하게 반대햇지만, 지금 생각해보니 결국 "좋은 코드는" (뭐가 어찌됐건) 쉽게 읽히는 코드라는 것을 다시 한번 느끼게 되었다. 그러기 위해서는 단순함과 맥락이라는 어찌보면 상반된 두 마리 토끼를 다 잡아야 한다고 생각이 든다
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
// 불용어 : 인터넷 검색시 검색용어로 사용하지 않는 단어로 검색색인 단어로 의미가 없는 단어 (ex 관사, 전치사, 조사, 접속사)