Каково Ваше отношение к трудному кодированию? [закрытый]

I always create a constant, but close as possible/sensible to where its "only" use is to be.

If I then need it somewhere else in the unit, it gets moved to the top of the unit.

If its then needed in another unit, the constant gets moved to a settings unit.

If someone wants it changable it gets moved to the settings unit (if not already), and set from a config file etc.

At the end of the day the name you give the thing is its documentation, at the very least it means you don't get your 73 mixed up with someone elses 73. If you see what I mean.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если кто-то скажет вам сделать глупый поступок, сохраните цепочку писем и сохраните свое ЗАДАНИЕ

Жесткое кодирование - это правильный выбор!

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

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

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

Как говорит Айенде ,

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

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

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

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

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

LinkWriter.href=configuration["supportUrl"]

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

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

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

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

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

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

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

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

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

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

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

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

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

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