
하드코딩한 매직넘버는 상수로써 표현하자
ds_chanin
·2025. 2. 21. 03:09
들어가며
코드리뷰 사항 중 꽤 개선하기 쉬운 부분이다.
그런데 생각보다 잘 지켜지지 않는 부분인것 같기도 하다.
프로그래밍에서 상수(static final)로 선언하지 않은 숫자를 매직 넘버, 문자열을 매직 리터럴이라 한다.
이를 정적(static)이고 변경 불가능(final)한 상수로 선언하여 사용하자.
간혹 단순히 값을 옮겨적는것이 상수로 표현한다고 착각하는 경우도 있는 것 같다.
해피케이스와 배드케이스로 나누어 살펴보도록 하자
문제상황
예전에 대학생때 다른 블로그에 써둔 주제가 동일해서 그대로 가져왔다.
AS-IS
public class Noise {
private final double decibel;
public Noise(double decibel) {
validate(decibel);
this.decibel = decibel;
}
private void validate(double decibel) {
if (decibel < 10.0) {
throw new IllegalArgumentException();
}
}
}
여기서 문제는~?
decibel < 10.0 처럼 비교하고 있는 구문에서 문제가 발생한다.
10.0이라는 숫자가 어떤 의미를 가지고 있는지 파악할 수 있을까?
이처럼 코드에서 상수로 선언되어 있지 않은 숫자, 문자열은 무엇을 의미하는지 확신할 수 없다.
따라서 그 의미를 파악하기 위해 클래스를 이해하고, 코드의 흐름을 이해하기 위한 시간과 노력이 필요하게 된다.
이를 상수로 선언하게 됨으로써 불분명한 값들은 이름을 가지게 된다.
이름을 가지게 된 값은 그 이름만으로도 어떠한 역할을 하는지 알 수 있게된다.
해피케이스
아래와 같이 바꿔보자
public class Noise {
private static final double BREATH_NOISE = 10.0;
private final double decibel;
public Noise(double decibel) {
validate(decibel);
this.decibel = decibel;
}
private void validate(double decibel) {
if (decibel < BREATH_NOISE) {
throw new IllegalArgumentException();
}
}
}
10.0이라는 매직넘버를 BREATH_NOISE 라는 상수로 추출하여 비교하던 값이 숨소리 라는 것을 알 수 있게 되었다.
명확한 의미를 드러내 코드를 읽는 사람으로 하여금 파악을 쉽게할 수 있도록 하자~
배드케이스
그런데 아래처럼 바꾸는 건 의미가 없다.
public class Noise {
private static final double TEN = 10.0;
private final double decibel;
public Noise(double decibel) {
validate(decibel);
this.decibel = decibel;
}
private void validate(double decibel) {
if (decibel < TEN) {
throw new IllegalArgumentException();
}
}
}
10.0을 TEN으로 바꿨다.
이건 번역한거랑 다를 바가 없다!
이처럼 무의미한 상수 선언은 상수로써 효용성이 없으니 위와 같이 바꾸지 않도록 조심하자~!
마치며
그런데 항상 상수로 선언하는게 좋냐? 라는 질문에는 아니라고 답할 것 같다.
진리의 케바케라는 말이 있듯이 상황에 따라서는 상수로 선언하지 않고 그대로 값을 노출시켜 사용하는게 가독성을 향상시키는 경우도 있다.
대표적으로 exception 내부에 선언한 메세지같은 경우가 그런것 같다.
그래도 어지간한 상황은 상수로 선언하는게 더 좋으니 일단 바꿔보고 행간의 의미를 다시 살펴보는 연습을 하도록 하자~
예전에 다른 블로그에 써두었던 글: https://javabom.tistory.com/28
'스터디 > 코드리뷰' 카테고리의 다른 글
테스트 코드에는 일련의 로직을 넣지 말자 (0) | 2025.02.23 |
---|---|
테스트도 단일책임원칙을 지키자 (0) | 2025.02.19 |
생성자 내부에서 너무 많은 일을 하지 말자 (0) | 2025.02.19 |
Exception을 테스트 할 때 거짓 음성을 주의하자 (0) | 2025.02.18 |
코드 리뷰 요청에 정성을 담아보자 (0) | 2025.02.18 |