DAY4

🔖 오늘 읽은 범위 : 2장, 의미있는 코드 (p. 22 ~ p. 25)

😃 책에서 기억하고 싶은 내용을 써보세요.

💡 의도를 분명히 밝혀라

• 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 많다. 그러므로 이름을 주의 깊게 살펴 더 나은 이름이 떠오르면 개선하기 바란다. 그러면 (자신을 포함해) 코드를 읽는 사람이 좀 더 행복해지리라. (p. 22)
• 의도가 드러나는 이름을 사용하면 코드 이해와 변경이 쉬워진다. (p. 22)

int elapsedTimeInDays;
int daysSinceCreation;
int daysSinceModification;
int fileAgeInDays;

• 단순히 이름만 고쳤는데도 함수가 하는 일을 이해하기 쉬워졌다. 바로 이것이 좋은 이름이 주는 위력이다. (p. 24)

// Before Naming
public List<int[]> getThem() {
  List<int[]> list1 = new ArrayList<int[]>();
  for (int[] x : theList)
    if (x[0] == 4)
      list1.add(x);
  return list1;
}

// After Naming
public List<Cell> getFlaggedCells() {
    List<Cell> flaggedCells = new ArrayList<Cell>();
    for (Cell cell : gameBoard)
      if (cell.isFlagged())
        flaggedCells.add(cell);
    return flaggedCells;
}

💡 그릇된 정보를 피하라

• 프로그래머는 코드에 그릇된 단서를 남겨서는 안 된다. 그릇된 단서는 코드 의미를 흐린다. 나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안 된다. (p. 24)
• 여러 계정을 그룹으로 묶을 때, 실제 List가 아니라면 accountList라 명명하지 않는다. 프로그래머에게 List라는 단어는 특수한 의미다. (p. 24)
• 서로 흡사한 이름을 사용하지 않도록 주의한다. 유사한 개념은 유사한 표기법을 사용한다. 이것도 정보다. 일관성이 떨어지는 표기법은 그릇된 정보다. (p. 24~25)
• 이름으로 그릇된 정보를 제공하는 진짜 끔찍한 예가 소문자 L이나 대문자 O 변수다. 두 변수를 한꺼번에 사용하면 더욱 끔찍해진다. 다음 코드에서 보듯, 소문자 L은 숫자 1처럼 보이고 대문자 O는 숫자 0처럼 보인다. (p. 25)

int a = l;
if ( O == l)
a = Ol;
else
l = Ol;

🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

✨ 의도를 분명히 밝히고 그릇된 정보를 피하자.

👉🏻 1년 차 신입으로 들어왔을 때의 많은 고충들이 생각이 나는 하루다. 나는 나름 전공자이지만 비전공자와 다를게 없다 생각하여 교육원에 들어가 훈련을 받은 학생이었다. 프로젝트를 할 때마다 시간에 쫓겨 변수의 이름, 클래스의 이름, 함수의 이름 나름 잘 지었다라고 생각하며 대충 넘어간 습관들이 첫 회사에 와서 안좋으 버릇이 되었다. 너무 뚜렷히 기억은 안나지만 내가 여러 사람들을 표현했을 때의 변수명들이다.

let personOne = undefined;
let personTwo = undefined;
let personThree = undefined;

어떤 프로젝트였는지 뚜렷히 기억은 안나지만 다음과 같이 변수명을 짓고 나서 너무나도 아무렇지 않게 PR(Pull Request)를 보낸 적이 있다. 그 때 날라온 Comment는 다음과 같았다.
"지훈님, 변수도 나름 생명체에요. 변수를 사랑해주세요."
이번 2장을 읽다보니 그 날이 떠오른다. 변수에게 의도를 분명히 밝혀주고 그릇된 정보를 피했어야했다. 이 책을 보면서 다시 한 번 리마인드 중이다. 기억하자. "변수를 사랑하자."