Part 2. 이름에

Part 2

이름에 정보 담기

함수명, 변수명을 짓는 것은 프로그래머가 가장 어려워하는 것.

예전에 나는 이것이 농담이야, 장난처럼 던지는 말이지 !

라고 말을 했었으나 이 글을 읽는 사람들이라면 다들 '요놈 짜식보게' 라고 말을 할지도 모른다.

이름에 정보를 담아내라.

특정한 단어 고르기.

보편적인 이름 피하기.

추상적인 이름 대신 구체적인 이름 사용하기.

접두사 혹은 접미사로 이름에 추가적인 정보 덧붙이기.

추가적인 정보를 담을 수 있게 이름 구성하기.

차근차근 위의 문장들을 읽어보아야한다.

가장 흔히 하는 나의 문제는 어느 한 단어에 꽂힌다는 것이다.

다른 사람의 코드를 보고나면 좋은 점을 배우고 돌아오는데

항상 여기에서 꽂힌 단어는 계속 내 코드에 등장하기 마련이다.

한참 initialize 라는 단어에 빠져있을 때였는데 어떻게 적어도 참 예쁜 단어였기에 자주 이용하고는 했다.

정말 간단한 함수이지만 함수명을 보기만 해도 어떻게 쓰였는지 확인이 가능하여

지금 다시보자니 칭찬할만한ㄷ...

어찌보면 참 길어보인다.

단어의 길고 짧은 상황은 범위에 따라 유효하다고 한다.

현재의 상황에는 길게 명을 짓는 것이 괜찮다고 생각이 들었다.

하지만 반대로 

이 상황에서의 x축, y축, width값, height값은 짧게 명을 지어도 무방하다고 생각한다.

한가지 더 유용한 점을 적어보자면,

알고리즘 문제를 풀 때 자주 있는 실수 중에 하나였는데.

이 책을 통해 좋은 습관을 만들어 낼 수 있을거 같다.

위 문제는 HackerRank 문제 중 String: Making Anagrams 이다.

여기서 가장 흔하게 착각하는것 중에 하나가 바로 i 이다.

물론 한 번의 for문은 문제가 없지만 이것이 이중, 삼중으로 겹쳐간다면

읽는 것에 방해가 될 수 있다.

listA, listB의 인덱스를 표현하는 의미를 부여하면

작은 실수로 인해 찾아오는 문제점은 확실히 줄여나아갈 수 있다.

---

*

사실 지금 돌아보니 과거의 내가 적은 코딩이 지금보다 더 나아보이기도 한다.

한시라도 빨리 취업해야해. 

프로젝트 하나로는 부족해. 

뛰어야지 지금은 뛰어야 내가 다른 친구들보다 멀리가지.

이러한 생각들이 여유를 앗아가지 않았나싶다.

지금의 나는 옳은 길을 걸어가고 있는가 물어보고 싶다.

차선책을 항상 떠올리며 방법들을 나열하고 제시하고 경우의 수를 따지고,

너무나도 복잡하고 계산적인 삶의 연속이 아닌가.

---

읽기 좋은 코드가 좋은 코드다.

더스틴 보즈웰, 트레버 파우커 지음 - 임백준 옮김

한빛미디어