2023. 3. 11. 16:12ㆍ카테고리 없음
1) 의도를 분명히 밝혀라
- 변수명은 그 쓰임새나 의도를 분명히 표현할 수 있어야 누가 보더라도 금방 쉽게 파악할 수 있다.
- 지뢰찾기 게임에 쓰이는 게임판 thsList 라는 변수를 gameBoard로 바꾸면 그 사용처를 명확히 알 수 있다.
2) 그릇된 정보를 피하라
- 데이터 타입이 List가 아님에도 accountList 라고 정의하면 그릇된 정보를 제공하는 것과 같다.
- 특히 i, o 같이 숫자와 비슷한 형태의 변수는 큰 혼동을 준다.
3) 의미있게 구분하라
- a1, a2, a3 같은 연속적인 숫자로 이루어진 변수명 지양
- 테이터 타입 String을 덧붙이거나 variable, table 같이 당연하거나 부가정보에 대한 표현 지양
4) 발음하기 쉬운 이름을 사용하라
- 내부적으로 쓰이는 단어들의 첫글자를 따 도대체 읽을 수 없는 외계단어를 생산해내지 말 것
5) 검색하기 쉬운 이름을 사용하라
- 의도가 명확히 표현된 변수명을 사용하면 특별히 많이 겹치는 부분이 없을 것
- 숫자나 프로그래밍 언어 키워드 같은 소스상 많은 부분에서 검색될만한 이름은 지양
6) 인코딩을 피하라
- 어떤 패키지의 어떤 클래스인지 혹은 변수인지 등에 대한 명세를 이름에 나타낼 필요는 없다.
7) 자신의 기억력을 자랑하지마라
- 일반적으로 사용되는 룰에 따라 정의하자, 반복분의 인덱스 i, j, k ... 처럼
8) 클래스 이름
- 명사나 명사구가 적합하다.
- Manager, Processor, Data, Info 등과 같은 단어는 피하고 동사는 사용하지 않는다.
9) 메서드 이름
- 동사나 동사구가 적합하다.
- 접근자, 변경자, 조건자는 자바빈 표준에 따라 앞쪽에 get, set, is 를 넣는다.
10) 기발한 이름은 피하라
- 특정 문화에서만 사용되는 언어는 피하고 의도를 분명히 솔직하게 표현하는 것이 중요하다.
11) 한 개념에 한 단어를 사용하라
- 조회의 경우 fetch, select, retrieve, get ... 같은 개념이지만 달리 표현하는데 하나만 사용하도록 룰을 정하자.
12) 말장난을 하지 마라
- 같은 맥락이 아닌데도 11)번 처럼 일관성을 유지한답시고 사용하면 코드가 어색해질 수 있다.
13) 해법 영역에서 가져온 이름을 사용하라
- api 통신에 feign client 라이브러리를 사용했다면, 이름에 해당 라이브러리를 나타내는 단어를 표현해줘도 좋다.
14) 문제 영역에서 가져온 이름을 사용하라
- 문제 영역 개념과 관련이 깊은 코드라면 해당 영역의 이름을 사용하라.
15) 의미있는 맥락을 추가하라
- street, city, state, zipcode 이들의 조합으로 보면 주소정보라는 것을 알 수 있지만 city 하나만 보고서는 의미 파악 어려움
- 위와 같을 때에는 addr이라는 접두어를 붙여 addrStreet, addrCity ... 처럼 더 큰 구조에 속한다는 것을 표현하자.
16) 불필요한 맥락을 없애자
- 빠른배송서비스 (Fast Delivery Service) 의 경우 각 단어의 앞글자를 따 FDS로 사용하는것은 바람직하지 않다.
- 일반적으론 짧은 이름이 긴 이름보다는 좋지만, 의미가 분명한 경우에 한해 적용되는 개념이다.