이름에 정보 담기

이 장의 핵심은 제목 그대로 이름에 정보를 담아내는 것이다.
이 장에서 다룰 것은 아래와 같다.

• 특정 단어 고르기
• 보편적인 이름 피하기 (혹은 언제 그런 이름을 사용해야 하는지 깨닫기)
• 추상적인 이름 대신 구체적인 이름 사용하기
• 접두사 혹은 접미사로 이름에 추가적인 정보 덧붙이기
• 이름이 얼마나 길어져도 좋은지 결정하기
• 추가적인 정보를 담을 수 있게 이름 구성하기

이렇게 정보를 표혀하는 좋은 이름을 선택하는 방법을 알아볼 것이다.

특정한 단어 고르기

이름에 정보를 담아내는 방법 중 하나는 매우 구체적인 단어를 선택해 무의미한 단어를 피하는 것이다.
다음 표는 어떤 단어와 그 단어보다 상황에 더 적합할 수 있는 단어를 예로 나열했다.

이런 대안이 있지만, 재치 있는 이름보다 명확하고 간결한 것이 더 좋다.

보편적인 이름 피하기

temp, retval, foo 같은 이름은 너무 무의미하다. 값이나 목적을 명확하게 설명하는 이름을 골라야한다.
retval 같은 경우 딱봐도 return value인것은 알지만 어떤 value를 반환해주는지 알 수는 없다.
왜? - 정보가 그만큼이 끝이기 때문. 그래서 상황에 맞는 이름으로 대체하는 것이 디버깅할 때 버그가 잘 드러날 것이다.
여기서 보편적인 이름을 한가지에서는 사용해도 괜찮다고 한다.
대표적인 예가 void swap(int a, int b); 이다.

void swap(int a, int b){
    int temp = a;
    a = b;
    b = temp;
}

이렇게 지역 변수로만 사용하고 소멸되는 경우에 임시 저장 이외에 다른 용도가 없다는 것을 잘 알 수 있는 경우이다.
근데 이런게 아니라 저 temp변수를 다른데서 또 사용하게 된다면 그때는 변수명을 변경해야 할 것이다.

temp라는 이름은 대상이 짧게 임시적으로만 존재하고, 임시적 존재 자체가 변수의 가장 중요한 용도일 때에 한해서 사용해야 한다.

다중 for문은 for(int i) → for(int j) → for(int k) 이런식으로 쓰는 것보다 어떤 인덱스인지 정보를 표기하는게 더 쉽게 표현이 될 것이다.

정리 - 보편적인 이름을 사용하려면, 꼭 그렇게 해야만 하는 이유가 있어야 된다❗️

추상적인 이름보다 구체적인 이름을 선호해라

뭔가를 나타내지만 두루뭉술하게 작성한 추상적 이름보다는 조금 더 구체적으로 덜 자극적인 새로운 이름으로 대체해야 한다.

추가적인 정보를 이름에 추가하기

단위를 포함하는 값들 - 변수가 시간의 양, 바이트의 수와 같은 측정치를 담고 있다면, 변수명에 단위를 포함시키는 것이 도움됨.
변수 뒤에 단위를 snake_case형식으로 명시해주는 것이 좋은 방법이다.

그리고 추가적인 정보를 붙이는 기술은 단위에만 한정되지 않는다.
unsafe 변수를 안전하다면 새로 safe변수에 담아주던지 어떠한 것의 비밀번호인지 명시해주는
xxx의 비밀번호 → xxx_password 이렇게 변환해주는 것이 좋다❗️

이름은 얼마나 길어야 하는가

막연하게 메소드가 어디에 있고 어떤 역할을 수행하는지에 대한 정보를 모두 메소드명에 담으면 길어지기 마련이다.

그래서 좁은 범위에서는 짧게 축약하는게 좋다.
또 너무 길어져서 축약을 하고 싶어도 뭔가 협업하는 사람들 내에 뉴비가 오지 않는다는 전제하에 그리고 다 소스를 숙지하고 있는 경우가 아니라면 '우리만' 알게 해서는 안된다. 그래서 BackEnd 를 BE이렇게 줄여서 쓰면 안된다는 것이다.
그렇지만 개발자들이 많이들 사용하는 document는 doc, string은 str 이런 흔한 경우를 제외하고는 줄여쓰는 것은 권장하지 않는다.

그리고 굳이 쓰지 않아야할 단어는 제거하는것이 좋다.
ConvertToString()의 convert가 없어도 문자열로 변환하는 것을 알고 있다.
이럴 때에 제거하는것이 바람직 하다❗️

이름 포맷팅으로 의미를 전달

멤버 변수, 상수, 지역 변수를 알기 쉽게 바꾸는 것이 좋다.
ex) public static final VALUE_OF_CONSTANT;

2장을 읽으면서는 로직만 죽어라 구현하는 것이 개발이 아니라 하나하나 로직을 짜더라도 천천히 심도있게 그리고 알아볼 수 있게 읽기 쉽게 설정하며 개발을 해야겠다고 생각했다.
2장 포스팅을 여기서 마친다.