개발자 99% 커뮤니티에서 수다 떨어요!
TIL (Today I Learned)
2022.02.20
오늘 읽은 범위
2장. 의미 있는 이름: 팀 오팅어(Tim Ottinger)
책에서 기억하고 싶은 내용을 써보세요.
이름은 변수명에도, 함수명에도, 파일에도 여러 곳에서 사용된다. 즉 이름을 잘 지어두면 여러모로 편하다. (p. 22)
의도를 분명히 밝혀라 (p.22)
이미 변수명을 지어 사용 중이라도 나중에 더 좋은 이름이 떠오르면 개선하라. (1장에 나왔듯 다시 소스를 보게 된다면 하나라도 개선을 하라는 내용과 비슷한 내용인듯)
이름에 주석이 달린다면 잘못 지어진 이름이다.
변수명이 조금 길어 지더라도 명확하게 하는 일과 변수의 의도가 드러나도록 지어보자.
그릇된 정보를 피하라 (p. 24)
잘못된 약어나, 소문자 L (l), O (o) 와 같은 문자가 변수명 또는 코드 자체에 포함되면 소스를 잘못 파악할 수 있으므로 사용할 때 주의하라.
요즘 IDE는 자동완성 기능이 충분히 잘 되어 있어 위에서 이야기 했듯이 이름이 조금 길어도 무리없이 사용 가능하니 적확한 이름을 사용하라.
같은 소스상에 비슷한 이름을 사용하면 헷갈릴 수도 있다.
또한 유사한 개념은 유사한 표기법을 사용해 정보를 제공해야 한다. 일관성이 떨어지면 그릇된 정보가 될 것이다.
의미있게 구분하라 (p. 25)
변수명을 짓기 귀찮다고 a1, a2 같은 의미도 없고, 그릇된 정보를 제공하는 이름도 아니며, 아무런 정보도 제공하지 못하는 이름은 피하라. (이름이 달라야 한다면 의미도 달라야 한다.)
구분이 되지 않는 비슷한 이름은 피하라.
customer vs customerInfo
getActiveAccount vs getActiveAccounts
변수명에 variable, 표에 table 같은 문자를 사용하지 말라. 더 나은 방법을 찾아라.
의도가 분명하고, 그릇된 정보를 피하면서 의미있게 지으면 된다...😂
발음하기 쉬운 이름을 사용하라 (p. 27)
날짜 변수를 genymdhms 라고 지어 부르는 회사가 있었더란다...그냥 읽기 쉽게 generationTimestamp 처럼 사용하라.
검색하기 쉬운 이름을 사용하라 (p. 28)
문자 하나로 변수명을 지으면 끔찍한 검색 지옥이 펼쳐질 것이다.
다만 간단한 로컬 변수명이나 메서드에서는 사용해도 괜찮을 것이다.
역시 조금 길더라도 제대로 이름을 지어라.
어쨌든 나중을 위해 검색하기 쉬운 이름을 지어라.
인코딩을 피하라 (p. 29)
헝가리식 표기법 (예전 변수명 길이가 제한되던 시절)
변수명 제일 앞에 타입을 알 수 있도록 타입의 줄임말을 접두어로 사용
int sValue = usValue; // s 는 safe us는 Unsafe 의 줄임말 (약자)
요즘 IDE의 발달로 여간해서 사용하지 말자.
멤버 변수 접두어
멤버 변수앞에 m_ 를 접두어를 붙이는 방식
역시 IDE의 발달로 사용하지 말라.
인터페이스 클래스와 구현 클래스
구현 클래스 이름을 사용하는게 낫다라고 하는데 이 부분은 읽어도 잘 모르겠다.
자신의 기억력을 자랑하지 마라 (p. 31)
반복문의 변수를 제외하고 한 문자로 변수명을 짓지말라. (위에서는 짧은 로컬변수에는 써도 된다며???)
명료함이 최고
클래스 이름과 메서드 이름 (p. 32)
클래스 이름과 객체의 이름은 명사나 명사구가 적합
Good : Customer, WikiPage, Account, AddressParse
Bad : Manager, Processor, Data, Info
메서드 이름은 동사나 동사구가 적합
Good : postPayment, deletePage, save
get, set, is 를 붙여도 좋다.
메서드에 인수가 있다면 인수를 설명하는 이름을 사용하자.
Complex fulcrumPoint = Complex.FromRealNumber(23.0);
기발한 이름은 피하라 (p. 32)
재미난 이름보다는 명료한 이름을 선택하라.
의도를 분명하고 솔직하게 표현하라.
한 개념에 한 단어를 사용하라 (p. 33)
get, fetch, retrieve 등 비슷한 의미의 단어가 있다면 그 중 하나만 사용하라는 의미인 듯
일관성 있는 어휘는 코드를 사용할 프로그래머에게 선물이다.
말장난을 하지 마라 (p. 34)
한 단어를 두 가지 목적으로 사용하지 마라.
일관성을 고려해라. 하지만 의미가 다르다면 과감하게 새로운 단어를 선택하라.
add (추가), insert (삽입), append(덧붙인다) 등
해법 영역에서 가져온 이름을 사용하라 (p. 34)
코드를 읽는 사람도 프로그래머이다.
전산용어, 알고리즘 이름, 패턴 이름, 수학 용어 등은 사용해도 괜찮다.
문제 영역에서 가져온 이름을 사용하라 (p. 34)
적절한 프로그래머 용어가 없다면 문제 영역에서 이름을 가져와라.
우수한 프로그래머라면 해법 영역과, 문제 영역을 구분할 줄 알아야 한다.
문제 영역 개념과 관련이 깊은 코드라면 문제 영역에서 이름을 가져와야 한다.
의미있는 맥락을 추가하라 (p.35)
가끔 접두어를 추가하면 맥락이 더 분명해지는 변수명들이 있다. 그럴 경우에는 접두어를 사용해 보도록 하라.
불필요한 맥락을 없애라 (p. 37)
일반적으로 짧은 이름이 긴 이름보다 좋다. 단 의미가 분명한 경우에 한해서다. 이름에 불필요한 맥락을 추가하지 않도록 주의하자.
좋은 이름을 선택하려면 설명 능력이 뛰어나야 하고 문화적인 배경이 같아야 한다. 좋은 이름을 선택하는 능력은 교육의 문제다.
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
이름 하나 짓는것이 얼마나 어려운 일인지 새삼 깨닫게 되었다. 항상 변수명 작성할 때 고민에 고민을 거듭하다 대충 짓고 마는데 오늘 정리한 내용을 가지고 많은 고민을 많이 해 봐야겠다.
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.