IT is Smart

문자 하나만 사용하는 변수명은 문제가 있다. 루프에서 반복 횟수를 세는 변수 i, j, k는 괜찮다. 단, 루프 범위가 아주 작고 다른 이름과 충돌하지 않을 때만 괜찮다. 루프에서 반복 횟수 변수는 전통적으로 한 글자를 사용하기 때문이다.그 외에는 대부분 적절하지 못하다. ※ 로버트 C 마틴의 클린 코드 참고

과거에는 컴파일러가 타입을 점검하지 않아서 타입을 확인할 수 있도록 이름에 타입을 포함했었다.하지만 요즘은 IDE가 컴파일하지 않고도 타입 오류를 확인해 주기 때문에 변수, 함수, 클래스 이름에 타입을 함께 포함할 필요가 없다.이제는 헝카리식 표기법이나 기타 인코딩 방식이 오히려 방해가 될 뿐이다. 변수, 함수, 클래스 이름이나 타입을 바꾸기가 어려워지며, 읽기도 어려워진다. ※ 로버트 C 마틴의 클린 코드 참고

문자 하나를 사용하는 이름과 상수는 코드에서 쉽게 눈에 띄지 않는다. MAX_CLASSES_PER_STUDENT는 쉽게 찾을 수 있지만, 숫자 7은 은근히 까다롭다. 7이 들어가는 파일 이름이나 수식이 모두 검색되기 때문읻. 검색은 되지만 7을 사용한 의도가 다를 수도 있다. 상수는 여러 자리 숫자이고 누군가 상수 내 숫자 위치를 바꿨다면 문제는 더 심각해진다. 긴 이름이 짧은 이름보다 좋다. 검색하기 쉬운 이름이 상수보다 좋다. 개인적으로는 간단한 메서드에서 로컬 변수만 한 문자를 사용한다. 이름 길이는 범위 크기에 비례해야 한다. ※ 로버트 C 마틴의 클린 코드 참고

발음하기 어려운 이름은 토론하기도 어렵다. 프로그래밍은 사회 활동이다. 흔히 시간가 관련된 변수 명으로 genymdhms(generate date, year, month, day, hour, minute, second)와 같이 이름 짓는 경우가 종종 있다. 어떻게 발음해야 할지도 모르겠지만 설명하기도 쉽지 않다.generateTimestamp라고 이름 짓는 것이 훨씬 의미도 명확하고 변수명으로 설명하기도 좋다. ※ 로버트 C 마틴의 클린 코드 참고

컴파일러나 인터프리터만 통과하려는 생각에 스스로 문제를 일으키는 경우가 있다.예를 들어, 동일한 범위 안에서는 다른 두 개념에 같은 이름을 사용하지 못한다. 그래서 한쪽 이름을 마음대로 변경하려는 유혹에 빠지곤 한다. 철자를 살짝 바꿨다가 나중에 스펠링 오류를 고치는 순간 컴파일이 안되는 상황을 겪게 된다.컴파일러를 통과하더라도 연속된 숫자를 붙이거나 의미없는 문자를 추가하는 방식은 적절하지 못하다. 이름이 달라야 한다면 의미도 달라져야 한다.a1, a2와 같은 방식이 흔히 사용하는 방식이지만 아무런 의미가 없어 코드를 바로 이해하기 어렵게 만든다.또, Product라는 클래스가 있는데 다른 클래스를 ProductInfo 혹은 ProductData라고 이름 지으면 개념을 구분할 수 없이 그저 이름만 다르..

의도와 다른 의미의 정보를 코드에 남겨두면 안된다. 여러 계정을 그룹으로 묶을 때 실제 List가 아니면 accountList로 이름을 지으면 안된다. List는 프로그램에서 특정한 의미를 갖기 때문이다. 그러므로 accountGroup이나 단순히 Accounts라고 이름짓는게 좋다. 서로 비슷한 이름을 사용하는 것도 주의해야 한다.XYZControllerForEfficientHandlingOfStrings라는 이름을 사용하면서 XYZControllerForEfficientStorageOfStrings라는 이름을 같이 사용한다면 어떨까? 두 이름은 매우 비슷하다. 이름으로 그릇된 정보를 제공하는 진짜 끔찍한 예가 소문자 L이나 대문자 O변수이다. 두 변수를 한꺼번에 사용하면 더욱 끔찍해진다. 소문자 L은..