매직 넘버 제거 : 언제 "아니오"라고 말할 때입니까?

우리는 마술 숫자 (하드 코딩 된 값)가 프로그램에서 혼란을 겪을 수 있다는 것을 알고 있습니다. 특히 주석이없는 코드 섹션을 수정할 때가 있지만 선을 어디에서 그리는가?

예를 들어, 이틀 사이의 시간 (초)을 계산하는 함수가 있다면

seconds = num_days * 24 * 60 * 60

와

seconds = num_days * HOURS_PER_DAY * MINUTES_PER_HOUR * SECONDS_PER_MINUTE

어떤 시점에서 하드 코딩 된 값이 의미하는 바를 완전히 명백하게 결정하고 혼자 내버려 두겠습니까?

숫자 리터럴 대신 기호 상수를 사용해야하는 두 가지 이유가 있습니다.

1. 매직 넘버가 변경되면 유지 보수를 단순화합니다. 이것은 귀하의 예에는 적용되지 않습니다. 한 시간의 초 또는 하루의 시간이 변경 될 가능성은 극히 낮습니다.

2. 가독성을 향상시킵니다. "24 * 60 * 60"이라는 표현은 거의 모든 사람에게 분명합니다. "SECONDS_PER_DAY"도 마찬가지이지만 버그를 사냥하는 경우 SECONDS_PER_DAY가 올바르게 정의되어 있는지 확인해야합니다. 간결한 가치가 있습니다.

정확히 한 번 표시되고 프로그램의 나머지 부분과 독립적 인 매직 숫자의 경우 해당 숫자의 기호를 만들지 여부를 결정하는 것은 맛의 문제입니다. 의심 스러우면 계속해서 심볼을 만드십시오.

이 작업을 수행하지 마십시오 :

public static final int THREE = 3;

마법의 숫자를 절대로 사용하지 않는 규칙을 지키겠습니다.

동안

seconds = num_days * 24 * 60 * 60

크런치 모드에서 3-4 주 동안 하루 10 시간 동안 코딩 한 후 대부분의 시간 동안 완벽하게 읽을 수 있습니다.

seconds = num_days * HOURS_PER_DAY * MINUTES_PER_HOUR * SECONDS_PER_MINUTE

읽기가 훨씬 쉽습니다.

FrustratedWithFormsDesigner의 제안이 더 좋습니다.

seconds = num_days * DAYS_TO_SECOND_FACTOR

또는 더 나은

seconds = CONVERT_DAYS_TO_SECONDS(num_days)

피곤할 때 상황이 분명해지지 않습니다. 방어 적으로 코드를 작성하십시오 .

거절 할 시간은 거의 항상입니다. 하드 코딩 된 숫자를 사용하는 것이 더 쉬운 시간은 UI 레이아웃과 같은 장소에 있습니다. 양식에서 모든 컨트롤의 위치를 ​​지정하기위한 상수를 만드는 것은 매우 입체적이며 피곤합니다. 일반적으로 코드가 UI 디자이너에 의해 처리되는 경우 별로 중요하지 않습니다. ... UI가 동적으로 배치되거나 일부 앵커에 상대 위치를 사용하거나 직접 작성하지 않는 한. 이 경우 레이아웃에 의미있는 상수를 정의하는 것이 좋습니다. 그리고 "정확한"것을 정렬 / 위치시키기 위해 여기 또는 거기에서 퍼지 인자가 필요하다면, 그것은 또한 정의되어야합니다.

하지만 당신의 예제에서, 나는 대체한다는 생각 24 * 60 * 60으로하는 것이 DAYS_TO_SECONDS_FACTOR좋습니다.

문맥과 사용법이 완전히 명확하면 하드 코딩 된 값도 괜찮습니다. 그러나 이것은 판결 요청입니다 ...

예:

@rmx가 지적했듯이 0 또는 1을 사용하여 목록이 비어 있는지 확인하거나 루프의 경계에있는 것은 상수의 목적이 매우 명확한 경우의 예입니다.

숫자에 의미 나 목적을 고정시킬 수 없으면 멈 춥니 다.

seconds = num_days * HOURS_PER_DAY * MINUTES_PER_HOUR * SECONDS_PER_MINUTE

숫자를 사용하는 것보다 훨씬 쉽게 읽을 수 있습니다. (단일 SECONDS_PER_DAY상수 를 사용하여 더 읽기 쉽게 만들 수 있지만 완전히 별개의 문제입니다.)

코드를보고있는 개발자가 코드의 기능을 볼 수 있다고 가정하십시오. 그러나 그들이 또한 이유를 알고 있다고 가정하지 마십시오. 당신의 상수가 이유를 이해하는 데 도움이된다면 그것을 찾으십시오. 그렇지 않다면하지 마십시오.

하나의 답변에서 제안한 것처럼 너무 많은 상수로 끝나는 경우 파일에 수십 개의 상수가 있다고해도 가독성이 향상되지 않으므로 외부 구성 파일을 대신 사용하십시오.

아마 다음과 같은 것들에 "아니오"라고 말할 것입니다.

#define HTML_END_TAG "</html>"

그리고 분명히 "아니오"라고 말할 것 입니다 :

#define QUADRATIC_DISCRIMINANT_COEF 4
#define QUADRATIC_DENOMINATOR_COEF  2

다음과 같은 명백한 일에 상수 사용을 장려하기 위해 찾은 가장 좋은 예 중 하나는 다음과 같습니다 HOURS_PER_DAY.

우리는 물건이 개인의 작업 대기열에 얼마나 오래 앉아 있는지 계산했습니다. 요구 사항이 느슨하게 정의되었고 프로그래머 24는 여러 곳에서 하드 코딩 되었습니다. 결국 우리는 하루에 8 시간 만 일하는 24 시간 동안 문제에 앉아있는 사용자를 처벌하는 것이 불공평하다는 것을 깨달았습니다. 작업 이이 문제를 해결하고 동일한 문제가있는 다른 보고서를 볼 때 24 코드를 통해 grep / search하기가 어려웠습니다.HOURS_PER_DAY

나는 숫자가 완전히 일정하고 변경 가능성이 없다면 완벽하게 수용 가능하다고 생각합니다. 따라서 귀하의 경우 seconds = num_days * 24 * 60 * 60에는 괜찮습니다 (물론 루프 내에서 이런 종류의 계산을하는 것처럼 어리석은 일을하지 않는다고 가정)는 가독성보다 낫습니다 seconds = num_days * HOURS_PER_DAY * MINUTES_PER_HOUR * SECONDS_PER_MINUTE.

당신이 이런 나쁜 일을 할 때입니다.

lineOffset += 24; // 24 lines to a page

더 이상 페이지에 줄을 넣을 수 없거나 변경하려는 의도가 없더라도 언젠가 다시 귀찮게하기 때문에 상수 변수를 사용하십시오. 궁극적으로 요점은 가독성이며 CPU에 2주기의 계산을 저장하지 않습니다. 귀중한 바이트가 모든 가치를 위해 압착되었을 때 이것은 더 이상 1978 년이 아닙니다.

seconds = num_days * 24 * 60 * 60

완벽하게 괜찮습니다. 이것들은 결코 변하지 않기 때문에 실제로 마법의 숫자는 아닙니다.

합리적으로 변하거나 명백한 의미가없는 숫자는 변수에 넣어야합니다. 그것은 거의 모든 것을 의미합니다.

한 단위에서 다른 단위로 값을 변환하기 위해 상수 (마법 값)를 작성하지 마십시오. 변환하는 경우 말하기 방법 이름을 선호합니다. 이 예제에서는 DayToSeconds(num_days)"24"와 "60"의 의미가 명확하기 때문에이 방법은 예를 들어 내부적으로 분석법에 매직 값이 필요하지 않습니다.

이 경우에는 절대 초 / 분 / 시간을 사용하지 않습니다. TimeSpan / DateTime 만 사용합니다.

컨텍스트를 매개 변수로 사용하여 결정

예를 들어, "calculateSecondsBetween : aDay and : anotherDay"라는 함수가 있으면 함수 이름이 상당히 대표적이므로 해당 숫자의 기능에 대해 많은 설명을 할 필요가 없습니다.

또 다른 질문은 다른 방법으로 계산할 수있는 가능성은 무엇입니까? 때로는 똑같은 일을하는 많은 방법이 있으므로 미래의 프로그래머를 안내하고 사용하는 방법을 보여주기 위해 상수를 정의하면 도움이 될 수 있습니다.