Когда использовать константы в качестве параметров вместо магических значений

Question

Я прочитал (и в целом согласен), что для повышения читабельности кода вы должны использовать константы вместо магических чисел в качестве параметров метода. Например, используя PHP:

// no constants ////////////////////
function updateRecord($id) {
    if ($id == -1) {
        // update all records
    } else {
        // update record with "id = $id"
    }
}

updateRecord(-1); // future maintainer says: "wtf does -1 do?"
                  // and then has to jump to the function definition

// with constants: /////////////////

define('UPDATE_ALL', -1);

function updateRecord($id) {
    if ($id == UPDATE_ALL) {
        // update all records
    } else {
        // update record with "id = $id"
    }
}

updateRecord(UPDATE_ALL); // future maintainer says: "woot"

_{Да, это не лучший пример, я знаю ...}

Итак, я вижу, как это лучше, но возникает вопрос о том, как часто вы должны это делать? Если бы это было для каждой функции, вы бы получили метрический набор постоянных определений.

Где бы вы нарисовали линию? Всегда придерживайтесь констант по магическим числам или используйте смешанный подход в зависимости от использования рассматриваемой функции?

Answer 1

Итак, я вижу, как это лучше, но возникает вопрос, как часто вы должны это делать? Если бы это было для каждой функции, вы бы получили метрический набор постоянных определений.

Если каждая функция принимает "магические параметры", то вы уже делаете это ужасно неправильно .

Я бы всегда использовал константы. Если вы думаете, что это означает, что у вас слишком много констант, то это просто отражает другие недостатки в вашем дизайне.

Answer 2

Как вы уже отметили, будущие сопровождающие будут благодарны вам за четкое именование. Этот сопровождающий может быть даже вами, я поражаюсь снова и снова о том, как много я забываю о своем собственном коде и как трудно понять его снова, когда я некоторое время не работал над ним.

Я бы определенно пошел с константами до конца, как только область действия будет больше, чем, может быть, один короткий метод. Как только вы начнете передавать эти значения, ИМХО они должны быть определены как константы. Внутри метода комментарий может подойти. Это, однако, не помогает тем, кто вызывает ваш код, но не видит этот комментарий. Даже другой метод в том же классе следует рассматривать как «клиент API», который не должен знать о деталях реализации других методов, которые он вызывает в этом отношении.

С языками, поддерживающими «реальные» перечисления (например, ключевое слово Java enum, введенное в Java 5), ​​вы даже получаете безопасность типов и не рискуете проблемы уникальности, которые могут возникнуть, например, у целочисленных констант.

Answer 3

Я бы использовал его там, где это ..

• улучшает читабельность
• поможет вам вспомнить
• давайте посмотрим с первого взгляда что вы передаете в качестве аргумента

Возьмем, к примеру, PHP sort () . Это имеет смысл:

sort($array, SORT_NUMERIC);

Но будет ли это?

sort($array, 2); // Haven't actually dug in to see what it matches, but you get the point

Answer 4

Ну, это не проблема, если вы заключаете вещи в классы и используете константы классов. Я редко использую глобальные константы, за исключением путей к вещам.

Answer 5

Вы должны стараться сводить литералы в своем коде к абсолютному минимуму: каждый литерал является потенциальной проблемой, потому что ваша среда может измениться, и потому что другие разработчики могут не знать, что это значит.

Когда я начинаю проект, я всегда выделяю файл, который будет использоваться только для именованных констант, часто заключенный в класс, посвященный таковым, и я их свободно использую, поскольку природа моей работы требует этого. Все именованные константы находятся в этом файле и управляются из этого файла, что обеспечивает отличную организацию и контроль над именованными константами. Вы также можете организовать их в группы с комментариями или областями кода, и в зависимости от языка, вкладывать и строить один на другом.

Эта практика помогла мне бесконечные времена за эти годы.