Являются ли когда-нибудь жесткие литералы приемлемыми?

Question

База кода, над которой я сейчас работаю, завалена жестко закодированными значениями.

Я рассматриваю все жестко закодированные значения как запах кода и пытаюсь по возможности устранить их ... однако есть некоторые случаи, в которых я не уверен.

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

1. MyTextBox.Text = someCondition ? "Yes" : "No"
2. double myPercentage = myValue / 100;

В первом случае лучше всего создать класс, который позволяет мне выполнять MyHelper.Yes и MyHelper.No или, возможно, что-то подобное в файле конфигурации (хотя это вряд ли изменится и кто знает может ли быть случай, когда его использование будет чувствительным к регистру).

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

Может кто-нибудь предложить подходящий способ справиться с таким жестким кодированием? И кто-нибудь может вспомнить места, где жесткое кодирование является приемлемой практикой?

Answer 1

Не обычно (допустимы литералы с жестким кодированием)

Еще один способ взглянуть на это - использовать хорошее соглашение об именах. для констант, используемых вместо жестко закодированных литералов, документация в программе.

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

ИМХО, облегчение чтения программ должно быть второй натурой опытный софт профессионал. Сырые числа редко общаются осмысленно.

Дополнительное время, необходимое для использования именованной константы, сделает удобочитаемость кода (легко вспомнить) и полезность для будущего повторный майнинг (повторное использование кода).

Answer 2

Текст условий должен быть в файле ресурсов; вот для чего это.

Answer 3

нет.

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

Answer 4

Я склонен рассматривать его с точки зрения масштаба и размера проекта.

Несколько простых проектов, над которыми я работаю соло? Конечно, я много чего пишу. Инструменты я пишу, что только я буду когда-либо использовать? Конечно, если он выполнит свою работу.

Но, работая над большими, командными проектами? Я согласен, они подозрительны и обычно являются продуктом лени. Отметьте их для просмотра и посмотрите, сможете ли вы найти шаблон, где они могут быть абстрагированы.

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

Answer 5

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

Потребность может прийти во многих формах:

1. Значение используется во многих местах, и оно должно быть изменено программистом. В этом случае константа явно необходима.

2. Пользователь должен иметь возможность изменить значение.

Я не вижу необходимости избегать жесткого кодирования. Я вижу необходимость что-то менять, когда есть явная необходимость.

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

Answer 6

Помните, что вы забудете значение любого неочевидного жестко закодированного значения.

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

Пример Delphi:

Длина: = Длина * 0,3048; {0,3048 переводит футы в метры}

Answer 7

Ничего страшного, если вы не проводите рефакторинг, юнит-тестирование, рецензирование кода. И вы не хотите постоянных клиентов. Кого это волнует?

Answer 8

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

Answer 9

Обычно я добавляю набор вспомогательных методов для строк и чисел.

Например, когда у меня есть строки, такие как «да» и «нет», у меня есть функция с именем __, поэтому я вызываю __ («да»); который начинается в проекте, просто возвращая первый параметр, но когда мне нужно сделать более сложные вещи (например, internationaizaton), он уже есть, и в качестве параметра можно использовать ключ.

Другим примером является НДС (форма британского налога) в интернет-магазинах, недавно он изменился с 17,5% до 15%. Любой, кто жестко закодировал НДС, выполнив:

$vat = $price * 0.175;

должен был затем пройти через все ссылки и изменить его на 0,15, вместо этого супер полезным способом было бы иметь функцию или переменную для НДС.

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

Answer 10

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

По моему мнению, жесткое кодирование - это когда вы полагаете, что переменная / значение / определение и т. Д. Никогда не изменятся, и создаст весь ваш код на основе этого убеждения.

Примером такого жесткого кодирования является книга «Обучи себя за 24 часа», которую все должны избегать.