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

Ответ 1

Hardcoding - это то, чего следует избегать как можно больше.

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

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

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

Ответ 2

Серебряные пуль не существуют в ИТ.

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

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

Ответ 3

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

"Делать это правильно" означает концентрацию всего вашего жесткого кодирования в одном или двух модулях.

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

Существует несколько "правильных причин" для жесткого кодирования.

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

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

Ответ 4

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

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

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

Есть несколько "жестких кодировок лучших практик" . Я думаю, что никогда не надстройка:

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

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

Ответ 5

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

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

Ответ 6

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

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

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

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

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

Ответ 7

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

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

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

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

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

Ответ 8

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

Ответ 9

Жесткое кодирование - это путь!

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

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

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

Как Ayende говорит, жесткое кодирование всего является ключом к включению изменений.

Ответ 10

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

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

Ответ 11

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

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

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

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

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

Ответ 12

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

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

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

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

Ответ 13

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

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

Ответ 14

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

Ответ 15

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

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

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

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

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

Ответ 16

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

Ответ 17

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

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

Однако этот тип анти-шаблона чрезвычайно распространен:

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

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

LinkWriter.href=configuration["supportUrl"]

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

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

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

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

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