Is Belt and Braces programming good practice or ju

Question

I was wondering whether using a Belt and Braces (Suspenders) approach to programming - and to data validation in particular - was good practice or not. This came about from the following example.

I was creating a form and I added Listeners to all the fields which should mean that the OK button is only enabled if all the fields in the form have valid values. I was then writing the code which was run when the OK button is clicked.

The pessimistic side of me decided that Belt and Braces never hurt anyone and it couldn't hurt to validate the form again in case there's a bug in my form logic.

But then I didn't know what to put in if the validation fails. If I do something like this:

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

then I have to create code to display an error message which should never be shown. Anyone maintaining this code in future is then going to worry about and possibly be confused by this in theory needless dialog. The last thing I want is someone wondering why this particular dialog is never displayed.

An option at the other end of the scale is:

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

Frankly, I feel dirty even typing that but perhaps there's a good reason to use it which I have missed.

So finally I ended up with:

assert form.isValid();

However, the downside of that is that it's not really belt and braces since the braces aren't there at run-time so if there is a bug in the code my form's trousers are still going to fall down as it were.

So maybe I shouldn't have the extra validation at all, but there's still a part of me which thinks it couldn't hurt.

I'd be interested to hear what you do in similar situations.

(Edit: the question is asking what is the best way to ensure the form returns valid data. Assume that the output of the form is validated again before it ends up in the database and so on.)

Answer 1

I'd recommend looking at this from a purely usability perspective. How are your users supposed to work while filling in forms? Most of the time, doing validation on both the control and the form level is what I'd recommend. Of course, there are many user interaction styles you can use:

1. Let the users do what they please, and then check on their results on OK. This can be excellent for expert users, allowing them to input things quickly and incrementally, but leaves newbies and infrequent users rather at a loss.
2. Validate each control as it's entered or on leaving. This can be good, especially for complex forms (which of course we shouldn't design, ever, really, but...!); but done poorly can prevent people from filling in forms incrementally in their own order. I prefer a visual indication that something's amiss if I do this.
3. Make it impossible to enter anything wrong. This can (almost) be achieved through e.g. sliders for numbers, combo boxes for restricted scalars, auto-validated edit boxes which prevent bad entries.

However, even in case 3, there are some cases where you have to check whether combinations of values are valid. I've worked with some cases where the values in some subsets of controls are dependent on each other (governed by an equation). It's not always feasible or worth the effort to provide the user with immediate feedback in these cases, so a case can always be made for validating on OK.

I'd agree with Binary Worrier that the OK check is the main one. If you're sure it should never fail, be sure to log a warning if it triggers, and sniff such events through your support channels if possible, but don't make the end user pay for programming errors.

Answer 2

In web (no pun intended) programming one would always take this approach because you can't depend on the client-side validation actually running; a crafty user can construct a form post or URL that simulates your client and sends data back to the server.

In a standalone app, it is less clear. I would suggest that it depends on where the validation is occurring. For example, if your validation runs in your business logic, not in your UI, then your validation ought to run every time. Using separation of concerns, the business logic shouldn't depend on the UI to do validation. After all, the business logic may be called from a typical GUI, a web app, or even an API.

One thing that I would suggest is that doubling up the validation logic in the UI, is probably overkill -- but you ought to be able to handle errors arising from the underlying layers. In this case, the errors might arise from validation.

Answer 3

I would also say that double validation never hurt anyone, and can only increase security.

I'd also like to bring up a point about your business logic. I assume this is a Winforms application, but the principle applies to the web as well. The UI should not be enforcing business logic. It's fine to put validation there, but it also needs to be in the business logic.

Answer 4

I don't do much UI work, but recently I found myself doing something very similar. I left in both the belt (validate each control as it changes) and the braces (check is valid again on OK_Click).

I left both in on the basis that if some future change missed validation on the control, it would be caught when the OK button is clicked.

In my head the check on OK is the real validation, and the per control validation is sugar that just enhances the users experience.

That said I haven't thought about it too much, and I don't often do UI work.

Answer 5

Whatever else you decide to do, just make sure you log the unexpected state and make the program fail somehow to prevent data corruption. Personally I think that is required and sufficient for a case where I'm not expecting an error.

Answer 6

I think that belt and braces is not a good practice.

If extreme reliability is required, as the case is for example with spaceship software, then the way to guarantee it is by providing multiple different implementations that run in parallel, are all provided the same input, and are all expected to provide the same output. Clearly, that's not belt and braces, it is something else.

If extreme reliability is not an issue, then belt and braces really only complicates things precisely in the ways that you discovered by yourself.

The assertion that you ended up with is the best thing to do, because assertions are meant to catch bugs and to document the code, and that's precisely what is happening in the situation at hand: if the form is not valid at the point of your assertion, then you have a bug elsewhere in your form, and the assertion is essentially documenting the fact that at this point in your code you expect that the validity of the form has already been taken care of. Also, the possibility of this bug happening should be eliminated during the testing phase of your application, so it should never happen in production, which is again in par with the purpose and intended use of assertions.

If you really like the belt and braces paradigm, then you can still consider the assertion as part of a belt and braces scheme, but in the right context: testing. This assertion is belt and braces during testing, because it guarantees that you have done all the right tests elsewhere in your code.