클린코드
의미있는 이름을 사용하라 클린코드
성구님
2017. 4. 15. 00:10
의도를 분명히 밝혀라
그릇된 정보를 피하라
의미 있게 구분하라
발음하기 쉬운 이름을 사용하라
검색하기 쉬운 이름을 사용하라
인코딩을 피하라
자신의 기억력을 자랑하지 마라
클래스 이름
메서드 이름
기발한 이름은 피해라
한 개념에 한 단어를 사용하라
말장난을 하지 마라
해법 영역에서 가져온 이름을 사용하라
문제 영역에서 가져온 이름을 사용하라
의미 있는 맥락을 추구하라
불필요한 맥락을 없애라
[의도를 분명히 밝혀라]
- 코드의 함축성을 줄여야 한다.
- 코드를 읽는 사람이 특정 정보를 안다고 생각하면 안된다.
- 상수는 명시적인 의미있는 이름으로 대처해도 좋다.
- 함수의 이름은 명시적으로
[그릇된 정보를 피하라]
- 줄인 단어는 사용을 줄여라.
- 서로 흡사한 이름은 사용 주의
[의미 있게 구분하라]
- 컴파일러나 인터프린터만 통과한다고 좋은 코드는 아니다.
- 비슷해보이는, 둥그스름한 표현은 좋지않다.
[발음하기 쉬운 이름을 사용하라]
- 발음이 쉬우면 쉽게 읽힌다.
[검색하기 쉬운 이름을 사용하라]
- 단순한 상수는 검색이 어렵다
- 그래서 의미를 내포한 열거형 변수로 만드는게 좋을 듯
[인코딩을 피하라]
- 이름에 유형이나 범위 등의 부가정보를 넣으면 읽기 어렵다.
- 헝가리식 표기법
- 좋지않다.
- 변수명에 변수형에 대한 정보가 있다.
- 변수형 변경 시 변수명도 모두 변경되야한다.
- 멤버 변수 접두어
- 클래스나 함수는 멤버 변수에 m_ 접두어를 붙일 필요가 없을 정도로 작아야좋다.
- 인터페이스 클래스와 구현 클래스
- 인터페이스에 접두어는 좋지않은 듯.
- 인터페이스보단 구현클래스의 이름을 인코딩하는게 좋다.
- 아마... 인터페이스가 좀 더 상위의 의미를 내포해서?
[자신의 기억력을 자랑하지 마라]
- 코드를 읽으며 변수명을 자신이 아는 이름으로 변환해야 한다면
- 그 변수이름은 바람직하지 못하다.
- 도메인 영역과 맞지않는 이름이기 때문에
- 문자 하나만 사용하는 변수는 루프문에서만.
- 명료함이 최고다.
[클래스 이름]
- 클래스와 객체명은 명사나 명사구가 적합하다.
- 동사는 좋지않다.
- 행위를 하는 주체가 아니기 때문인가??
[메서드 이름]
- 메서드명은 동사나 동사구가 적합하다.
- 접근자, 변경자, 조건자는
- get, set, is로 표현하는게 좋다.
[기발한 이름은 피해라]
- 재미난 이름보단 명료한 이름을
[한 개념에 한 단어를 사용하라]
- 추상적인 개념 하나에 단어 하나
- 똑같은 메서드를 클래스마다 다른 이름으로 선언하면 혼란스럽다.
- 일관성있는 어휘를
[말장난을 하지 마라]
- 한 단어를 두 가지 목적으로 사용하면 좋지않다.
- 대충 훑어봐도 이해할 수 있는 코드가 목표다.
[해법 영역에서 가져온 이름을 사용하라]
- 코드를 읽는 사람도 프로그래머이기 때문에
- 전산용어, 알고리즘 등 컴퓨터 프로그래밍 전문어를 사용하는 것도 괜찮다.
- 해법 영역에서 가져온 이름을 사용하라는 것은 결국
- 문제를 해결하면서 드는 전문적인 분야의 것들을 사용해도 좋다는 것 같다.
[문제 영역에서 가져온 이름을 사용하라]
- 적절한 프로그래밍 용어가 없다면 문제 영역의 이름을 사용한다.
- 문제 영역은 해당 분야 전문가에게 물어봐 의미를 파악할 수 있다.
[의미 있는 맥락을 추구하라]
- 하나의 의미를 내포하는 그룹은 그 의미를 부여하는 맥락을 부여하면 좋다.
- 예를 들어 zipcode(), state(), city()등은 주소에서 사용된다고 치면
- 각 메서드 앞에 addr을 붙여주면 이해하기 쉽다
- 그리고 다른 곳에서 재사용 시 의미 파악이 쉽다.
- 맥락 파악이 쉬워 알고리즘이 명확해지는 효과도 있다.
[불필요한 맥락을 없애라]
- 의미있는 짧은 이름은 긴 이름보다 좋다.
- 재사용할 수 있는 이름이 좋다.
- 맥락을 너무 깊숙히 내포하면 재사용이 까다롭다.
- 코드의 맥락을 잘 파악해 의미를 붙이거나
- 붙이지않거나...