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

Мне было интересно, следует ли использовать метод Belt and Braces (Suspenders) для программирования и, в частности, для валидации данных - это хорошая практика или нет, Это произошло из следующего примера.

Я создавал форму, и я добавил Listeners во все поля, которые должны означать, что кнопка OK включена, только если все поля в форме имеют допустимые значения. Затем я записывал код, который запускался при нажатии кнопки OK.

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

Но тогда я не знал, что положить, если проверка не удалась. Если я сделаю что-то вроде этого:

if (! form.isValid()) {
  displayErrorMessage();
}

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

Опция на другом конце шкалы:

if (! form.isValid()) {
  throw new RuntimeException("This should never happen!");
}

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

Итак, в итоге я закончил:

assert form.isValid();

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

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

Мне было бы интересно узнать, что вы делаете в подобных ситуациях.

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

Ответы

Ответ 1

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

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

В моей голове проверка OK - это проверка реальная, и проверка на управление является сахаром, который просто увеличивает опыт пользователей.

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

Ответ 2

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

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

Ответ 3

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

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

Изменить. Что касается веб-программирования, javascript обычно используется для проверки, прежде чем входы будут отправлены на сервер. Очевидно, этого недостаточно, поскольку пользователи могут отключить javascript и обойти эту проверку, поэтому в этом случае необходима проверка на стороне сервера. В любом случае, когда пользователь мог злонамеренно или случайно обойти первую строку проверки, необходимо также выполнить двойную проверку на внутреннем сервере. Я предполагаю, что это не проблема в Java, С# и т.д.

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

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

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

Ответ 7

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

  • Пусть пользователи делают то, что им нравится, а затем проверяют их результаты на OK. Это может быть превосходным для опытных пользователей, позволяя им быстро и постепенно вводить информацию, но оставляет малолетних и нечастых пользователей в убытке.
  • Проверяйте каждый элемент управления, когда он вводится или уходит. Это может быть хорошо, особенно для сложных форм (которые, конечно же, мы не должны проектировать, когда-либо, но...!); но сделано плохо, может помешать людям постепенно заполнять формы в своем собственном порядке. Я предпочитаю визуальное указание, что что-то не так, если я это сделаю.
  • Невозможно ввести что-либо неправильно. Это может (почти) быть достигнуто посредством, например, ползунки для чисел, комбинированные поля для ограниченных скаляров, авто-проверенные поля редактирования, которые предотвращают плохие записи.

Однако даже в случае 3 есть некоторые случаи, когда вам нужно проверить, действительно ли сочетания значений. Я работал с некоторыми случаями, когда значения в некоторых подмножествах элементов управления зависят друг от друга (определяется уравнением). Это не всегда осуществимо или стоит усилий, чтобы предоставить пользователю немедленную обратную связь в этих случаях, поэтому всегда можно сделать дело для проверки на OK.

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

Ответ 8

Я собираюсь дать невероятно непопулярный ответ.

Мой ответ: зависит от.

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

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

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

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

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

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

Да. О, да...

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

В противном случае он не нужен.

Ответ 9

Я думаю, что пояс и скобки не являются хорошей практикой.

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

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

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

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