메서드, 변수, 클래스 등등 우리는 작업을 할때 무수히 많은 이름들을 정한다. 그래서 좋은 이름은 개발자들의 필수 덕목이다.
우리는 코딩을 할때 반드시 다른 사람과의 협업을 생각해야 한다. 그게 나의 파트너가 될 수도 있고 선임이 될 수도 있고 또는 새로 들어온 후임이 될 수도 있다. 각기 다른 위치의 여러 사람들이 내 코드를 읽는 독자가 된다.
최근 기술의 발달로 인텔리제이나 VSC 같은 IDE 에서는 .만 찍어도 뒤에 무슨 메서드를 사용할지 추천을 해준다. 하지만 아쉽게도 메서드의 이름만 출력될 뿐이지 주석까지 같이 알려주지는 않는다. 우리는 우리의 독자들에게 알기 쉬운 코드를 선보여야 한다. 가독성을 높이기 위해선 옆에 주석을 주렁 주렁 다는 것 보다는 이름을 읽고 이 변수가 무슨 일을 하는지 한번에 알수 있는게 중요하다. 가독성이 높아지면 일의 효율이 늘어난다. 쓰기 귀찮다고 혹은 너무 길어진다고 이름을 짧게 만들려고만 하지말고 어느 정도 길어지더라도 확실한 의미가 있고 발음하기 쉬운 이름을 정하는 것이 중요하다.
좋은 이름을 쓰기위해 중요한 것은 다음과 같다.
- 이름이 의도를 분명히 밝혀야 한다.
- 발음하기 쉬워야 한다.
- 기발한 이름은 피해라 / 말장난을 피해라.
- 그릇된 정보가 섞이는 것을 주의 해라.
개인적인 소감
이번 챕터를 읽으면서 뜨끔한 부분이 꽤 많다. 주로 이름을 쓰기 귀찮아서 String 의 변수 이름을 그냥 s로 짓는 다던지 혹은 메서드의 이름을 나만 아는 언어로 대충 때운다던지... 대부분 개인 프로젝트여서 그랬겠지만, 나의 기억력을 믿지 말라던 로버트 작가님의 일침이 날카로웠다. 생각해보니 이름만 잘 지어도 코드를 복기할때 걸리는 시간이 많이 줄 것 같다. 좋은 코드는 주석도 필요 없이 이해가 되는 코드라고 하니 앞으로는 시간이 좀 걸려도 이름을 확실히 하고 가는 습관을 길러야겠다.
기억에 남았던 구절들
문제는 코드의 단순성이 아니라 코드의 함축성이다.(p.23)
일관성이 떨어지는 표기법은 그릇된 정보다.(p.25)
NameString이 Name보다 뭐가 나은가? Name이 부동소수가 될 가능성이 있던가? 그렇다면 앞서 언급한 "그릇된 정보를 피하라" 규칙을 위반한다.(p.26)
이름의 길이는 범위 크기에 비례해야 한다.(p.28)
똑똑한 프로그래머와 전문가 프로그래머 사이에서 나타나는 차이점 하나만 들자면, 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다. 전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다.(p.32)
