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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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