[번역] 변수명 짓기 팁 7+1

1. 변수명은 최대한 많은 것을 설명해야 합니다. 일반적인 명칭들을 사용하지 마세요.

 

좋은 예: daysDateRange, flightNumber, carColor

나쁜 예: days, dRange, temp, data, aux

 

많은 개발자들이 많은 것을 설명하는 변수명보다 짧은 변수명을 선호합니다. 왜냐하면 소스를 작성할 때 시간을 아낄 수 있기 때문이죠. 이건 소프트웨어 질을 개선 시키는데 도움이 되지 못합니다. 그저 하루에 몇 분 아끼게 될 뿐이죠. 하지만 설명적인 변수명은 읽기 쉽고 수정하기 쉽기 때문에 소프트웨어 질을 향상 시킵니다. 

 

 

2. 변수명은 최대한 짧게 지으세요.

 

이 규칙은 첫 번째 규칙과 어느 정도 상충되는 면이 있는 부분입니다만

최대한 설명적이면서 가능한 짧은 변수명을 지어야 합니다.

단순히 짧은 이름보다 설명적인 부분을 좀 더 우선순위에 두고 이름을 지으라는 의미이고

 

설명적인 변수명 중에서 가장 짧은 것을 고르라는 의미입니다.

 

 

3. 약어를 사용하는 것은 좋습니다. 다만 주석을 통해 약어를 설명하도록 하세요.

많은 것을 설명하는 변수명을 사용하기 위해 변수명이 조금 길어지는 것은 괜찮습니다.

그렇지만 약어를 이용해 변수명의 길이를 개선하고자 한다면 

변수명을 선언한 곳에 주석을 이용해 변수명의 의미를 잘 설명해두세요.

 

 

4. 필요하다면 적절한 헝가리안 표기법을 사용하세요.

조엘 온 소프트웨어에 헝가리안 표기법을 어떻게 사용하는 것이 좋은지 설명한 글이 있습니다.

하나의 함수를 작성할 때 같은 데이터이지만 타입이 다를 때 헝가리안 표기법은 도움이 될 수 있습니다.

 

 

5. 변수명을 부정적인 의미로 짓지 마세요.

 

좋은예: IsEnabled.

나쁜예: IsNotEnabled.

 

부정적인 표현보다 긍정적인 표현이 더 쉽게 읽고 이해할 수 있습니다.

 

 

6. 만약 한 함수에서 "손님"이라는 변수명을 사용했다면 다음 함수에서 "고객"이라고 부르지 마세요.

하나의 함수에서 약어를 사용하였다면 다른 모든 함수에서도 동일하게 적용하세요.

 

 

7. 각기 다른 도메인에서, 서로 다른 컨셉들은 매우 특정적이고 다른 의미를 갖습니다.

(예를 들면 "Order"가 모든 도메인에서 같은 의미를 갖지 않습니다.)

특정 컨셉에 맞춰 변수명들을 계획하세요.

비지니스 도메인의 컨셉에 맞는 이름을 지을 때 그 의미가 정확히 표현될 수 있도록 하세요.

만약 고객이 "Order"를 승인하다의 의미로 생각하고 있다면 승인되지 않음을 그냥 "Order"로 부르지 말고  "nonApprovedOrder" 라고 부르세요.

 

 

골든 규칙 - 시간을 내서 당신의 변수명을 생각해보세요.

잠깐의 시간조차 내지 않고 필요한 순간에 이름을 바로 정했다면 아마도 안좋은 이름을 선택했을 가능성이 높습니다. 좋은 변수명을 고르기 위해 항상 몇 분씩을 할애 한다면 코드에 있는 좋은 변수명에 상당히 만족할 수 있을 것입니다.

원문: http://www.makinggoodsoftware.com/2009/05/04/71-tips-for-naming-variables/