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

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

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

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

$vat = $price * 0.175;

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

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

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

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

Примером такого трудного кодирования является книга, Учат Себе C за 24 Часа, что все должны избежать.

У меня когда-то был босс, который отказался к не hardcode что-то, потому что в его уме это дало ему полный контроль над программным обеспечением и объектами, связанными с программным обеспечением. Проблема была, когда аппаратные средства перестали работать, который запустил программное обеспечение, в которое сервер был переименован... означая, что он должен был найти свой код. Это требовало времени. Я просто нашел Hex-редактор и бездельничал он вместо ожидания.

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

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

Я не думаю, что Ваша секунда является действительно примером жесткого кодирования. Это похоже на наличие Делить на два () метод, который берет в значении для использования для деления на; не имеет смысла.

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

Трудного кодирования нужно избежать как Dracula, избегает солнца. Это возвратится, чтобы укусить Вас в заднице в конечном счете.

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

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

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

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

Помните упущение значения любого неочевидного трудно кодированного значения.

Так обязательно поместите короткий комментарий после каждого для напоминания Вам.

Пример Delphi:

Длина: = Длина * 0.3048; {0.3048 преобразовывает ноги в метры}

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

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

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

Я действительно использую константы для вещей как названия тестовых файлов для сравнения.

Не обычно (Приемлемые литералы жесткого кодирования),

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

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

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

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

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

"жесткое кодирование" является неправильной вещью волноваться о. Точка не, являются ли специальные значения в коде или в файлах конфигурации, точка:

• Если значение могло бы когда-либо изменяться, каким количеством состоит в том работа, что и как трудно это должно найти? Помещение его на одно место и обращение к тому месту в другом месте не являются большой работой и поэтому способом избежать рискованных действий.
• Программисты maintainance определенно поймут, почему значение - каково это? Если существует сомнение вообще, используйте именованную константу, которая объясняет значение.

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

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

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

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

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

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

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

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

Лучший путь к Вашему второму примеру состоял бы в том, чтобы определить подставляемую функцию:

double getpercentage(double myValue)
{
   return(myValue / 100);
}

...

double myPercentage = getpercentage(myValue);

Тем путем намного более очевидно, что Вы делаете.

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

Случай 1: Когда должен Вы материал твердого кода: когда у Вас не будет причины думать, что это будет когда-либо изменяться. Тем не менее Вы никогда не должны трудно кодировать встроенный материал. Не торопитесь для создания статических переменных или глобальных переменных или независимо от того, что язык дает Вам. Сделайте их в рассматриваемом классе, и если Вы замечаете, что два класса или области Вашего кода совместно используют то же значение ПО ТОЙ ЖЕ ПРИЧИНЕ (значение, что это не просто совпадение), укажите на них на то же место.

Случай 2: Для случая случая 2, Вы корректны: законы "процента" не изменятся (быть разумным, здесь), таким образом, можно будет трудно кодировать встроенный.

Случай 3: третий случай - то, где Вы думаете, что вещь могла измениться, но Вы не хотите к / времени потрудиться загружать ResourceBundles или XML или что бы то ни было. В этом случае Вы используете любой механизм централизации, Вы можете - ненавистный Singleton-класс быть хорошим - и идти с этим, пока у Вас на самом деле нет потребности иметь дело с проблемой.

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

Править: Позвольте мне упомянуть, что я только что закончил проект рефакторинга, в котором предшествующий разработчик поместил строки подключения MySql в 100 + места в коде (PHP). Иногда они были прописными, иногда они были нижним регистром, и т.д., таким образом, их было трудно искать и заменить (хотя Netbeans и PDT действительно помогали много). Существуют причины, почему он сделал это (проект под названием POG в основном вызывает эту глупость), но нет только ничего, что меньше походит на хороший код, чем повторение того же самого в миллионе мест.

Это никогда не хорошо, и Вы просто доказали его...

double myPercentage = myValue / 100;

Это не процент. То, что Вы хотели записать:

double myPercentage = (myValue / 100) * 100;

Или более правильно:

double myPercentage = (myValue / myMaxValue) * 100;

Но это трудно кодировало 100 смешанных с Вашим умом... Поэтому пойдите для getPercentage метода что предложенный Colen :)

double getpercentage(double myValue, double maxValue)
{
   return (myValue / maxValue) * 100;
}

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

Реальный вопрос не о трудном кодировании, а скорее повторении. Если Вы слушаете превосходный совет, найденный в "Прагматически настроенном Программисте", просто не Повторяйте Себя (DRY).

Беря принцип DRY, это прекрасно к hardcode что-то в любой точке. Однако, после того как Вы используете то конкретное значение снова, осуществляете рефакторинг так это значение, только hardcoded однажды.

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

(Для примера этого возможно, интересно вернуться к goto войнам. Сколько программистов Вы знаете, что это будет клясться всеми вещами, святыми, что goto является злым? Почему затем Steve McConnell посвящает дюжину страниц измеренному обсуждению предмета в Завершенном Коде?)

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

Но это вовсе не значит то, что "самой простой вещью" не должен быть читаемый код. Может иметь смысл, даже в одноразовом скачке писать:

const MAX_CACHE_RECORDS = 50
foo = GetNewCache(MAX_CACHE_RECORDS)

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

Просто помните, если Вы идете на крайние меры материала как

const ONE_HUNDRED = 100
const ONE_HUNDRED_AND_ONE = 101

мы будем все приезжать в The Daily WTF и смеяться над Вами.:-)

Подумай! Это все.

нет.

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