[Clean Code] 2. 의미 있는 이름

오늘 읽은 범위

2장. 의미 있는 이름

책에서 기억하고 싶은 내용

• 문제는 코드의 단순성이 아니라 코드의 함축성이다. (p.23)
• 유사한 개념은 유사한 표기법을 사용한다. 이것도 정보다. 일관성이 떨어지는 표기법은 그릇된 정보다. (p.25)
• 이름 길이는 범위 크기에 비례해야 한다. 변수나 상수를 코드 여러 곳에서 사용한다면 검색하기 쉬운 이름이 바람직하다. (p.28)
• 추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다. 예를 들어, 똑같은 메서드를 클래스마다 fetch, retrieve, get으로 제각각 부르면 혼란스럽다. (p.33)
• 우수한 프로그래머와 설계자라면 해법 영역과 문제 영역을 구분할 줄 알아야 한다. 문제 영역 개념과 관련이 깊은 코드라면 문제 영역에서 이름을 가져와야 한다. (p.35)
• 일반적으로는 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다. 이름에 불필요한 맥락을 추가하지 않도록 주의한다. (p.37)

오늘 읽은 소감

2장을 읽고 나서 내가 깃허브에 정리해놓은 알고리즘 문제 풀이 코드들을 살펴보았다. 아래는 그 중 특히나 2장의 방향성에 어긋났던 소스 코드이다.

#플로이드
n = int(input())
INF = int(1e9)
graph = [[INF]*(n+1) for _ in range(n+1)]
m = int(input())
for _ in range(m):
  a, b, c = map(int, input().split())
  graph[a][b] = min(graph[a][b], c)

for a in range(1, n+1):
  graph[a][a] = 0

for k in range(1, n+1):
  for a in range(1, n+1):
    for b in range(1, n+1):
      graph[a][b] = min(graph[a][b], graph[a][k]+graph[k][b])

for a in range(1, n+1):
  for b in range(1, n+1):
    if graph[a][b]==INF:
      print(0, end=' ')
    else:
      print(graph[a][b], end=' ')
  print()

n, m, a, b, c... 코드 작성자인 본인조차 나중에 다시 코드를 확인할 때 변수의 의미를 파악하는 것에 있어서 어려움을 겪는데, 다른 사람들은 말할 필요도 없겠구나라는 생각이 들었다. 평소에 나만 읽게 될 코드를 작성하는 경우에도 '코드의 단순성'보다 '코드의 함축성'에 신경을 쓰는 습관을 들여야겠다.