Как вы относитесь к жесткому кодированию?

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

Если вы жестко закодируете что-то в своем коде, это полностью «уничтожит» переносимость вашего кода в отличном степень. Даже с независимыми от платформы языками вы не сможете сказать: «Скомпилировать один раз, запустить где угодно». Поскольку это не очень хорошая практика разработки программного обеспечения, я думаю, что лучше избегать жесткого кода.

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

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

Серебряных пуль в IT не существует.

• Сделай это, если умно.
• Не делай этого, если он тупой.

Если кто-то скажет вам сделать глупость, сохраните цепочку писем и сохраните свой J.O.B.

Нет ничего плохого в жестком кодировании, если оно сделано правильно по правильным причинам!

«Делать правильно» означает сосредоточить все ваше жесткое кодирование в одном или двух модулях.

Для C определите все значения в файле codes.h для Java есть класс code.java, который просто заполнен общедоступными константами.

Есть несколько «правильных причин» для жесткого кодирования.

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

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

Концептуально я не люблю слишком много жесткого кодирования.

Но на практике я стараюсь жестко кодировать некоторые значения. Основные причины жесткого кодирования:

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

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

• Жестко закодированные значения всегда следует объявлять в центре констант.
• Даже если значение жестко запрограммировано, его все равно следует передавать в качестве аргумента компонентам, которым не нужно заботиться о том, откуда взялось значение. Это делает ваш компонент многоразовым.

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

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

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

Во встроенном и критически важном программном обеспечении жесткое кодирование имеет два основных преимущества:

• это быстрее
• это проще

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

Обычно жестко закодированные данные помещаются в один файл заголовка для облегчения сопровождения.

Более того, гибкость обеспечивается за счет автоматического создания этого файла заголовка из базы данных.

Я думаю, что жесткое кодирование значений по умолчанию - это способ пойти на все, что может потребоваться для настройки:

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

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

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

Единственная проблема - задокументировать все ключи настроек ...

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

Жесткое кодирование - лучший способ!

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

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

Если вам нужны разные конфигурации для разных клиентов, не проблема, поместите жестко запрограммированные значения в их собственную сборку / dll и разверните разные сборки конфигурации для каждого клиента.

Как сообщает Айенде, жесткое кодирование всего - это ключ к разрешению изменений.

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

Для общесистемных констант я обычно создаю класс и создаю в нем константы.

Здесь задействовано несколько факторов, которые вряд ли охватят все случаи.

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

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

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

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

требуется меньше времени, чтобы получить то, что они хотели.

Это почти то же самое, что сказать: «Мне нравится писать свой код без комментариев, потому что мне нужно меньше времени, чтобы получить то, что я хотел».

Конечно, это не значит, что жесткое кодирование всегда очень плохо. (Я имею в виду, что было бы глупо хранить, скажем, математическую константу, такую ​​как π, e или постоянная Планка, в файле конфигурации. Кроме того, жесткое кодирование таблицы поиска, скажем, для значений синуса / косинуса, вероятно, быть намного эффективнее, чем загрузка их из файла.) Но жесткое кодирование данных исключительно ради удобства не является разумной идеей. Он негибкий и делает последующее изменение данных гораздо более проблематичным, чем должно быть.

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

Если мне нужно char *, чтобы указать на 12 символов, я могу спокойно написать malloc(12), потому что sizeof(char) всегда будет 1. Если мне нужно int *, чтобы указать на 12 целых чисел, я пишу malloc(12 * sizeof(int)).

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

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

Я всегда создаю константу, но как можно более близкую к тому месту, где должно быть ее «единственное» использование.

Если мне он понадобится где-то еще в блоке, он перемещается в верхнюю часть блока.

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

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

В конце концов, имя, которое вы даете этой вещи, является ее документацией, по крайней мере, это означает, что вы не путаете свой 73 с кем-то elses 73. Если вы понимаете, о чем я.

Что касается жестко закодированных строк в C / C ++; Я обычно # определяю их как самый простой способ избежать жесткого кодирования (хотя в некотором смысле он все еще жестко запрограммирован). Причина в том, что определенный идентификатор с ошибкой будет обнаружен компилятором, тогда как все, что находится в кавычках, не будет.

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

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

Однако крайне распространен этот тип антипаттерна:

File.Open(configuration["widgetsFileStorage"] + "/" + widgetImage)

Или это (вы бы когда-нибудь помещали вводимые пользователем данные непосредственно в href? Я бы не стал. Почему-то многие люди слишком доверяют значениям конфигурации).

LinkWriter.href=configuration["supportUrl"]

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

File.Open(new WidgetFileLocater().GetUncPath(widgetImage))

Где-то за моим локатором файлов я мог или не мог ссылаться на файл конфигурации, базу данных. Я, вероятно, начну жесткое кодирование в каталог «изображений» в каталоге приложения. Конфигурация возникает тогда, когда у нас есть вариант использования гибкости (кто-то хочет разместить ее в SAN?), Но не раньше. Во всяком случае, большую часть приложения не должно быть настроено, независимо от того, настроено оно или нет. Я бы, вероятно, использовал некоторую инъекцию зависимостей в локаторе файлов, чтобы убедиться, что он правильно обрабатывает паршивый ввод из файла конфигурации.

Также: Конфигурация почти всегда слабо типизирована, не компилируется и, следовательно, намного опаснее кода. Разработчики редко соблюдают этот риск (но очень уважают системные администраторы). Я обсуждал использование языка сценариев, такого как python / ironpython / boo, для нужд конфигурации. Я бы получил возможность изменять материал после компиляции с гораздо более свободным синтаксисом и проверкой типов, чем xml или текст.

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