1. 좋은 이름을 위한 고려 사항
•
보통 변수의 좋고 나쁨은 그 이름에 의해 좌우된다. 변수의 이름을 신중하게 선택해야 한다.
이름을 지을 때 가장 중요한 고려 사항
•
변수 이름을 지을 때 그 이름이 변수가 나타내고자 하는 바를 완전하고 정확하게 설명하는지를 가장 중요하게 생각해야 한다.
◦
미국 올림픽 대표팀 선수가 몇명인지 나타내는 변수의 이름은 numberOfPeopleOnTheUsOlympicTeam이 좋다.
•
이처럼 좋은 이름에는 두 가지 특징이 존재한다.
◦
하나는 해석하기 쉽다는 점이다. 변수 이름은 해석할 필요없이 바로 받아들일 수 있게끔 쉽게 읽을 수 있어야 한다.
◦
나머지 하나는 가능한 구체적이라는 점이다. 한 가지 이상의 목적으로 사용되기 쉬운 막연한 이름은 많은 정보를 제공하지도 않고 일반적으로 나쁜 이름이다.
문제 지향
•
좋은 이름은 일반적으로 해결책보다 문제에 대해서 서술하고 있는 경향이 있다.
◦
어떻게보다 무엇을 표현한다.
•
일반적으로 이름이 문제보다 해결 과정의 어떤 측면을 가리키고 있다면 이는 무엇보다는 어떻게에 대한 것이다. 문제 자체를 가리키는 이름이 좋다.
◦
직원의 데이터에 대한 레코드는 inputRec이나 employeeData가 될 수 있다.
◦
inputRec은 입력과 레코드라는 컴퓨팅 개념을 가리키는 컴퓨터 용어다. employeeData는 컴퓨팅보다는 문제 영역에 해당한다.
•
조금 더 도메인에 집중해서 표현하라는 의미로 받아들여도 될 것 같다.
최적의 이름 길이
•
최적의 길이는 존재하지 않는다. 너무 짧은 이름은 충분한 의미를 전달하지 못하고 너무 긴 이름은 외관상 우릴 읽기 두렵게 만든다.
•
너무 많지도 적지도 않은 상태로 유지하는 것이 좋다. 가급적 3, 4단어들의 조합까진 허용되는 것 같다.
범위가 변수명에 미치는 효과
•
짧은 변수 이름이 항상 나쁜 것일까? 그 변수의 수명이 짧다면 좋은 선택일지도 모른다.
•
범위가 짧다면 변수의 이름이 짧아도 충분하다는 의미다. 즉 그 변수를 해석하기에 너무 많은 정보가 존재하지 않으므로 단순해도 상관이 없다.
•
하지만 짧은 이름은 문제를 일으킬 가능성이 존재하므로 신중한 개발자들은 방어적으로 짧은 이름을 피하곤 한다.
◦
전역 네임스페이스에 있는 변수에는 한정자를 사용하라.
▪
변수가 전역 공간에 있다면 전역 공간을 나누고 이름 충돌을 피하기 위한 컨벤션을 고려해본다.
▪
이를 지원하지 않는다면 접두사로 서브시스템을 붙이는 것을 추천한다.
변수 이름의 계산값 한정자
•
많은 프로그램이 총계, 평균, 최댓값등 수학적 계산값을 보관하는 변수를 가진다.
•
total, sum, average와 같은 한정자를 변수의 이름에 넣는 경우, 이름 끝에 한정자를 입력한다.
◦
한 가지 예외는 num 한정자의 위치다.
▪
앞에 있는 경우, 총계를 가리킨다, 뒤에 있는 경우 인덱스를 가리킨다.
•
전체 고객의 수는 customerCount, 특정 고객을 가리킬때는 customerIndex를 사용하는 것이 좋다.
일반적인 변수명의 반의어
•
반의어를 두루뭉실하게 사용하지 말라. 반의어에 대한 컨벤션을 적절하게 사용하면 일관성을 유지하고 가독성을 높이는데 도움이 된다.
•
다음은 몇 가지 일반적인 반의어다.
◦
begin/end, first/last, locked/unlocked, min/max, next/previous, old/new, opened/closed, visible/invisible 등
2. 특정 타입의 데이터 이름 짓기
반복문 인덱스 변수명
•
반복문이 짧다면 i, j, k로도 충분하다.
•
반복문이 길어진다면 해석을 위해 충분히 힌트가 될만한 변수명을 사용하자.
상태 변수명
•
상태 변수에 flag보다 더 나은 이름을 생각해본다.
•
그 어떠한 단서도 제공하지 않기 때문에 프로그램 상에서 어떤 의미를 나타내는지 확인하고 이름을 지어보자.
•
열거형에도 이 접근방법을 사용할 수 있다.
임시 변수명
•
임시 변수는 계산의 중간 결과를 보관하기 위해 임시 저장소로 사용되고 보조 수단으로 사용하는 값을 보관하는데 사용된다.
◦
대개는 temp나 x같은 모호하고 이해하기 어려운 이름을 갖는다.
•
임시 변수는 개발자가 문제를 완벽하게 이해하기 있지 못한다는 신호로 상태 자체가 임시이기 때문에 개발자는 임시 변수를 다른 변수보다 별생각없이 다루게 되어 오류가 발생할 가능성이 높다.
•
가급적이면 이름을 지어주자.
불린 변수명
•
전형적인 불린 변수의 이름을 기억한다.
◦
done
▪
무언가가 수행되었다는 것을 가리키기 위해서 사용한다.
▪
이 변수는 반복문이 수행되었거나 다른 연산이 수행되었음을 가리킬 수 있다. 처리되기 전 done을 거짓으로 초기화하고 처리 후 참으로 변경한다.
◦
error
▪
오류가 발생했음을 가리키기 위해서 error를 사용한다. 오류가 발생했을 때, 이 변수는 참으로 설정하라.
◦
found
▪
값이 발견되었다는 것을 가리키기 위해서 found를 사용한다. 값이 발견되지 않았을 때 거짓으로 설정하라.
•
참이나 거짓의 의미를 함축하는 불린 변수의 이름을 사용한다.
•
긍정적인 불린 변수명을 사용한다.
◦
notFound가 true면 찾지 못했다는 부정의 의미가 참이 된다. 의미가 한 번 꼬인다.
◦
단순하게 found로 사용하라.
상수명
•
상수 이름은 상수가 가리키는 구체보단 상수가 표현하는 추상적인 개념을 표현해야 한다.
3. 이름 규약의 효과
왜 규약이 필요한가?
•
더 많은 것을 당연하게 받아들인다. 하나의 일관된 흐름을 가지게 되면 조금 더 집중해야하는 부분에 집중할 수 있다.
•
새로운 프로젝트도 좀 더 빠르게 코드를 배우게 해준다. 일관성있는 코드는 가독성이 좋고 이해하기 쉽다.
이름 규약 예제
•
변수 이름은 보통 세 가지 정보를 포함한다.
◦
변수의 내용
◦
데이터의 종류
◦
변수의 범위
5. 표준 접두사
•
표준 접두사는 사용자 정의형 축약어와 의미적 접두사로 구성된다.
◦
사용자 정의형
▪
이름이 있는 객체나 변수의 데이터형을 나타낸다.
▪
그 프로그램에서 사용하기 위해 표준화한 짧은 코드로 기술된다.
◦
의미적 접두사
▪
UDT보다 한 단계 더 나아가 변수나 객체가 어떻게 사용되는지 설명한다.
▪
프로젝트에 상관없이 어느정도 표준이 존재한다.
▪
c(count), g(global) 등이 존재한다.
6. 읽기 쉬운 짧은 이름
•
짧은 변수명을 사용하고자하는 바람은 구시대 유물이다. 축약어를 사용하면 쉽게 달성할 수 있으나 가급적 사용하지 않는 것이 좋다고 생각한다.
◦
가독성을 떨어트리고 잘못 사용했을때, 그 오해로부터 비롯되는 문제가 클 수 있다.
◦
그렇다고 특정한 영역에만 축약어를 사용하는 것은 일관성을 해치는 행위라고 생각한다. 사용할거면 사용하고 말거면 말아야한다.
7. 피해야 할 변수명
•
오해의 소지가 있는 이름이나 축약어를 피한다.
•
유사한 의미가 있는 이름은 피한다.
•
이름은 유사하지만 의미가 다른 변수를 피한다.
•
이름에 숫자를 넣는 것을 피한다.
•
스펠링이 틀리지 않도록 주의한다.
•
대소문자만으로 변수의 이름을 구분하지 않는다.
•
여러 가지 자연어를 섞지 않는다.
•
프로그래밍 언어의 키워드를 사용하지 않는다.
•
변수가 표현하는 것과 전혀 관련이 없는 이름을 사용하지 않는다.
•
혼자만 아는 어려운 단어를 피한다.
요점 정리
•
좋은 변수명은 프로그램의 가독성에 아주 중요한 요소다. 반복문 인덱스와 상태 변수와 같은 특정한 변수들은 각자의 사정을 고려해야 한다.
•
이름은 가능한 구체적이어야 좋다. 모호하거나 하나 이상의 목적으로 사용될 수 있는 이름은 나쁜 이름이다.
•
네이밍 컨벤션은 범위를 구분한다. 그리고 클래스, 상수, 열거형, 변수마다 달라야 한다.
•
변수명 네이밍 컨벤션은 선택사항이 아니다. 어떤 규약을 적용할지는 프로그램 특성마다 다르며 구성원들과 협의 후 결정해야 한다.
•
축약어는 사용하지 말자. 축약어를 사용해야 한다면 프로젝트 진행 전 축약어를 약속으로 정하거나 표준 접두사 접근 방법을 사용하라.
•
코드를 작성하는 시간보다 읽는 시간이 훨씬 더 길다. 작성하기 편리한 이름보다 읽기 쉬운 이름을 선택하라.
