6. 예측 가능한 코드를 작성하라
개발자는 코드를 사용하는 방법에 대한 정신 모델을 구축한다. 이 정신 모델은 코드 계약에서 발견한 것, 사전 지식, 적용할 수 있다고 생각하는 공통 패러다임에 근거해서 만들어진다. 코드가 실제로 하는 일이 이 정신 모델과 일치하지 않는다면, 예측과 벗어나는 기분 나쁜 일이 일어날 가능성이 크다.
6.1. 매직값을 반환하지 말아야 한다
매직값(magic value)은 함수의 정상적인 반환 유형에 적합하지만 특별한 의미를 가지고 있다.
ex: 오류 발생을 나타내는 ‘-1’ 반환 값
매직값은 그 값을 직접 사용하는 코드로 인해 버그를 유발할 수 있다.
그러므로 널, 옵셔널 또는 오류를 반환하는 코드로 변경하는 것을 추천
6.2. 널 객체 패턴을 적절히 사용하라
- 사용하지 말아야 하는 경우
- 오류 처리에 사용
- 의미가 있는 문자열을 반환 (ex. 아이디)
- 빈 값으로 채워진 객체를 반환
- 사용해도 되는 경우
- 빈 컬렉션 반환
- 의미가 없는 문자열 반환 (ex. 속성 값)
6.3. 예상치 못한 부수 효과를 피하라
부수 효과(side effect)는 어떤 함수의 호출이 함수 외부에 초래한 상태 변화를 의미한다.
부수 효과는 소프트웨어에서 무조건 필요 함. 단지 코드를 사용하는 쪽에서 예상하지 못한 부수 효과가 일어난다면 문제가 발생 할 수 있다. (ex. 버그 유발, 성능상 이슈)
예상하지 못한 부수 효과는 해당 코드와 분리하는 것이 원칙이며, 분리 할 수 없다면, 이름을 통해 부수 효과를 분명히 명시해야 한다.
6.4. 입력 매개변수를 수정하는 것에 주의하라
특수한 상황이 아니라면 입력 매개변수를 수정하지 말아야 한다. 입력 매개변수를 복사한 값을 수정하여 로직을 풀어나가라.
입력 매개변수 수정을 피할 수 없는 경우, 함수 이름과 문서에 입력 매개변수 수정이 이러난다는 것을 분명히 하는 것이 좋다.
6.5. 오해를 일으키는 함수는 작성하지 말라
로직에 필수적이거나 중요한 입력에 대해 유효하지 않은 값을 입력받는 경우 아무런 동작을 하지 않는 형태로 구현하면 안된다.
필수로 만들거나, 유효하지 않은 값이 입력된다면 예외를 발생 시키는 등 적극적으로 코드를 사용하는 쪽에 알려야 한다.
6.6. 미래를 대비한 열거형 처리
열거형을 사용한다면 if 대신 switch를 이용하라.
switch의 default를 사용하지 말고, switch 문 이후까지 도달 할 경우, 예외를 발생시켜라.
6.7. 이 모든 것을 테스트로 해결할 수는 없는가?
테스트는 매우 중요하다. 아무리 많은 코드 구조화나 코드 계약에 대한 걱정도 고품질의 철저한 테스트를 대체할 수 없다. 그러나 필자의 경험상 그 반대 역시 사실이다. 직관적이지 않거나 예상을 벗어나는 코드에 숨어 있는 오류를 테스트만으로는 방지하기 어렵다.