abstract
2장은 의미있는 이름에 대한 규칙의 모음이다. 이전에 내가 잘못 했던 부분들도 있었고, 옛날 교수님이 했던 얘기들도 생각나고, 같이 일하던 알고리즘을 특히 더 잘하는 몇몇 개발자에 대한 생각도 나고 감회가 새로웠다.
2장 의미 있는 이름
들어가기에 앞서 확실히 Clean Code는 어느정도 코드를 접해본 다음에 읽어볼 만한 책이라는 느낌이 좀 들었다. 이름 중요하다고 강조 안하는 선생님은 없을텐데, 솔직히 알파벳도 간당간당한 사람이 갑자기 토플 빈출 어휘 목록을 본다고 이해하길 바라는건 어렵지 않을까?
의도를 분명히 밝혀라.
변수나 함수 그리고 클래스 이름은 다음과 같은 굵직한 질문에 모두 답해야 한다. 변수(혹은 함수나 클래스)의 존재 이유는? 수행 기능은? 사용 방법은? 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.
// BAD
int d; // 경과 시간(단위: 날짜)
// GOOD
int elapsedTimeInDays;
int daysSinceCreation;
int daysSinceModification;
int fileAgeInDays;좋은 이름은 코드를 읽을 때 주석의 필요성을 덜어준다. 실제로 잘 작성된 코드는 큰 어려움 없이 동작이 생각되며 순서도를 그릴 수 있으며, 동작을 인간의 언어로 표현하기 좋다고 생각한다. 개인적으로는 Python(List Comphrehension 같은 기능을 제외한다면)이 가장 쉽게 인간의 언어로 표현할 수 있지 않을까 생각한다.
그릇된 정보를 피하라.
그릇된 단서는 코드 의미를 흐린다. 나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안된다.
책에서는 유닉스 플랫폼 hp와 직각삼각형의 빗변 hypotenuse의 약어 hp를 비유했다. hp와 UNIX를 같이 검색하니까 HP-UX가 나왔고 Hewlett Packard의 Enterprise 급 Unix 구현체란다. 그냥 Hewlett Packard랑 비슷한것도 있고 Hit Point 같기도 하고...
서로 흡사한 이름을 사용하지 않도록 주의해야 한다.
XYZControllerForEfficientHandlingOfStrings와 XYZControllerForEfficientStorageOfStrings는 비슷한 의미이며 비슷한 이름이 되며, 누가 어떤 역할을 하는지 알아보기 어려워진다. 물론 예시겠지만, 저 이름 자체가 너무 긴거 같기도 하고...
일관성이 떨어지는 표기법은 그릇된 정보다.
여기서 IDE의 기능의 발전이 처음 언급되었는데, 확실히 IDE들은 놀랍다. 특히 Java와 Intellij IDEA의 조합은 대단하다고 생각한다. 그래서 긴 이름에 대한 두려움 없이 작성할 수 있고, 이름이 길수록 자신의 의도를 컴퓨터한테 전달하기가 쉬워지면서 코딩 속도가 올라가는게 확연히 느껴진다.
일반적인 IDE는 가능한 식별자 목록을 보여주는데, 왠만한 상황에서는 딸린 모든 주석을 보여주기 어렵다 보니 아무래도 이름이 더 잘 보여야 한다는 것을 강조하면서 언급되었다.
의미있게 구분하라.
public static void copyChars(char[] a1, char[] a2) { for (int i = 0; i < a1.length; i++) { a2[i] = a1[i]; } }
a1과 a2 대신 source, destination을 사용하라는 이야기. 몇번째 것을 나타내는 1, 2, n 등을 사용하지 말라는 이야기. 평소에는 target을 써왔다.
발음하기 쉬운 이름을 사용하라.
class DtaRcrd102 { private Date genymdhms; } // ... class Customer { private Date generationTimestamp; }
위의 코드는 레코드의 생성일자를 지칭하기 위한 변수 이름이 존재하지 않는 언어로 되어있으니 지칭하기가 어렵다. 아래 코드는 generationTimestamp를 보라고 하면 바로 확인이 가능. 이건 Head First Design Pattern의 한장면이 떠올랐던 부분.
검색하기 쉬운 이름을 사용하라.
긴 이름이 짧은 이름보다 좋다.
(중략)
이름 길이는 범위 크기에 비례해야 한다.
회사에서 일할 때 서비스 개발보다 알고리즘을 더 많이 한 코딩 경력자가 두명 있었는데, 이사람들이 변수 이름을 a, s, d 등으로 만드는 걸 보고 기절할뻔 했다. 물론 Clean Code 책에서는 다른 이들의 철학도 존중할 것을 명시한 만큼, 알고리즘 할 때는 상관 없지만 적어도 나랑 일할 땐 (한사람은 같이 개발하진 않았다. 그사람은 영업직) 그러지 말자고 좀 과격하게 이야기했다.
인코딩을 피하라.
굳이 부담을 더하지 않아도 이름에 인코딩할 정보는 아주 많다.
변수 이름 등에 변수에 담긴 정보를 제외한 추가적인 정보 (타입, 선언 위치 등)을 추가하지 말라는 이야기.
헝가리안 표기법
헝가리안 표기법을 위키에서 찾아보면 몇가지 예시가 나온다.
bBusy:BooleanchInitial:charcApples: count of items
보면 변수 이름 앞에 타입에 대한 정보를 담는 글자가 한두개 포함이 되어있다는 점을 확인할 수 있다. 이는 예전 컴파일러들이 타입 체크를 안해주기 때문에(!!!) 발달한 방식으로 현재는 조금만 어긋나도 바로 빨간줄 뜨는 IDE들이 많으므로 굳이 안해도 된다.
멤버 변수 접두어
이전에 자료구조 강의를 듣는데 교수님이 코드를 작성하면서 miNodeCount(맞나?) 등의 변수 이름을 만들어서 사용하시더라. 이걸 더이상 할필요 없다는 의미.
인터페이스 클래스와 구현 클래스
이건 Spring 프로젝트 찾아보면 맨날 나오는 IService 시리즈를 말하는 부분인것 같다. 확실히 불편하다. 어차피 IoC는 인터페이스의 구현체를 찾아주는데, 굳이 해당 클래스가 인터페이스임을 나타내기 보단 어떤 구현 클래스가 어떤 방식으로 해당 인터페이스를 구현하는지를 이름에서 나타내는게 났지 않나? 라는 생각을 Spring 처음 배울 때부터 했는데, 여기서 확인을 받으니 기분이 좋다.
자신의 기억력을 자랑하지 마라
전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다.
이 장에서 제일 중요한 말이지 않을까 싶다.
클래스 이름 & 메서드 이름
클래스 이름과 객체 이름은 명사나 명사구, 메서드 이름은 동사나 동사구가 적합하다.
근데 Java에서는 보통 그렇게 썼는데 JS에서는 가끔 pinia나 vuex나 redux 같은 데서 본질은 메서드지만 값을 돌려줘서 메서드 이름도 명사형으로 썼던 기억이...
말장난을 하지 마라
add란 말을 특정 클래스에서 "더하기"의 의미로 사용했다면, 집합, 리스트 등을 구현할 때 요소를 "더한다"는 의미로 add를 사용하지 말라는 이야기. 아마 맥락까지 고려해야 하겠지만.
예를들어 Collection Framework의 인터페이스는 전부 데이터의 모음이니까 "더하기"는 "모음에 추가하기"를 나타낼 것이다. BigInteger 같은 특이 데이터용 클래스는 숫자를 다루니까 "더하기"는 "두 수를 더하기"를 나타낼 것이다.
해법 영역에서 가져온 이름을 사용하라
코드를 읽을 사람도 프로그래머라는 사실을 명심한다. 그러므로 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다.
고객(기획자)는 개발 용어를 사용하지 않고 설명하지만, 그걸 만족하는 개발 용어가 있다면 해당 용어를 이름으로 사용해도 된다는 의미.
불필요한 맥락을 없애라
모든 클래스를 동일한 단어나 문자로 시작한다면 자동완성을 하고자 할때 IDE가 모든 단어를 회수하려고 할것이며, 아무 도움이 안될것이다.
맺음말
이름을 항상 크고 아릅답게 지으려고 노력해왔는데, 크게 나쁘지 않은 행동이었다고 얘기해주는것 같아서 기분이 좋았다. 가끔 생각이 안나서 비슷한 이름도 지었던 적이 아예 없는건 아니었는데, 나중에 다시 확인하기 어려웠던 경험도 생각나고. 옛날에 만났던 사람들도 생각나는 장이었다.
여담
보고 웃은 얘기들
...어떤 경우는 코드 작성자가 글꼴을 바꿔 차이를 드러내는 해결책을 제안했다.
-- p.25 그릇된 정보를 피하라 중
...!!! ㄴㅇㄱ
...나는 쓰인 대로 발음하는 고질적인 습관이 있어 "젠 야 무다 힘즈"라고 읽었다.
-- p.27 발음하기 쉬운 이름을 사용하라 중
"젠 야" 하는데 "타"가 떠올랐다.
헝가리안 표기법
-- p.29 인코딩을 피하라 중
이건 사실 나무위키에서 정보처리기사 관련 정보를 찾아보다 발견한건데(제대로 준비하는게 아니라 심심해서 찾아보는 것이었지만) 문제점 문서의 '실무 위주의' 문제? 문단에서 헝가리안 표기법을 언급했던 것이 기억났다.
루프에서 반복 횟수를 세는 변수 i, j, k는 괜찮다. (l은 절대 안된다!)
-- p.31 자신의 기억력을 자랑하지 마라 중
근데 Intellij는 4중 for문 자동완성하면 l이 나온다. ㅋㅋㅋㅋㅋ
HolyHandGrenade라는 함수가 무엇을 하는지 알겠는가?
-- p.32 기발한 이름은 피해라 중
카르바노그의 토끼를 잡는데 사용하는 것이지
약간 미묘한 말들
컴파일러를 통과할지라도 ... 불용어를 추가하는 방식은 적절하지 못하다.
-- p.26 의미있게 구분하라 중
불용어(noise word)가 무슨말이지...? 검색하면 noise가 검색된다...이후 예시에서는
ProductInfo혹은ProductData라 부른다면 개념을 구분하지 않은 채 이름만 달리한 경우다.
라고 하는걸 보면 Info, Data같이 어떤 지칭하는 말을 하는거 같은데...
의미를 해독할 책임이 독자에게 있는 논문 모델이 아니라 의도를 밝힐 책임이 저자에게 있는 잡지 모델이 바람직하다.
-- p.34 말장난을 하지 마라 중
논문이랑 친하지 않아서 잘 모르겠지만, 논문도 결국 의도를 밝힐 책임이 저자에게 있는거......아닌가? 물론 엄청난 양의 전문지식이 배경에 있어야 읽을 수 있겠지만
의미 있는 맥락을 추가하라 부분은 스킵했다. 조금 논의의 여지가 있다고 보인다.
+ 제출하고 나서 본 인증샷
