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

From my experience, "just in case" code is sometimes a symptom of lazy programming. I.e., I've found a solution that basically works, I'm not sure it will always work, so I'll throw in some double-checking code "just in case." If you're not sending rocket ships to the moon, this type of thing is relatively harmless, but can be very bad practice nonetheless.

For my (non-rocket-ship) business applications, I always put in error logging and a friendly message, and try to think the problem all the way through so that the users see the friendly message as infrequently as possible. If there is a problem, I'm better able to fix it because my code isn't cluttered up with all kinds of unnecessarily checks.

Answer 2

My coworkers generally do double-validate inputs, "just in case." I think it would depend largely on the people you work with or who will have to maintain your code. If you always double-validate, they will quickly catch on as to what you're doing. If you only sometimes double-validate, they will likely be confused. Perhaps you should consult with coworkers as to their habits? If you work alone or in a very small group, it would probably be okay to double-validate your inputs.

If I were to take over your code, I think the important thing is probably following a convention, either always or never put validation in both places. At least that way I wouldn't get confused.

Edit: As far as web programming goes, javascript is generally used to validate before inputs are sent to the server. Obviously, this isn't enough as users can turn off javascript and circumvent that validation, so server-side validation is necessary in that case. In any case where a user could maliciously or accidentally circumvent the first line of validation, it's imperative to also double-check on the back-end. I imagine this is less of a problem in Java, C#, etc.

Answer 3

I'm going to give an incredibly unpopular answer.

My answer is: it depends.

Before people start rising up from their chairs in indignation and add extra froth to their latte' from venting their rage, hear me out.

I modify an ERP package that uses shared files. Don't laugh, it's the day job. Anyways, the system has a single flaw in the design - it validates the data upon input, and then always assumes it is correct due to that one-time validation, once it writes records out.

This sounds like a reasonable approach until you run into missing data fields, crashed sessions, machines with bad RAM that you can't see, machines with spotty LAN connections that go undetected, and occasionally a bug (or two) in the programming language itself. Records are half-written, fields may go missing data, indexes occasionally just implode for no reason...the list goes on.

Now, the vendor that provides the software very much runs against belt-and-suspenders because, hey, time is money, and they're in business to sell their product (software). Every 15 minutes of time writing additional sanity checks is 15 minutes that could be spent generating revenue. But they don't get paged at 3am to fix crashed sessions or release nasty deadlocks. I do.

So I add the rough equivilent of asserts into the procedures, functions, and methods that I write. I do sanity checks on the data types passed (it makes all variables variants), I attempt to cross-reference data when possible, and I look for other signs of "insanity" in the code. When a routine finds something that resembles the twilight zone, it gives a diagnostic dialog (which the user typically screen-shots and forwards to me) and then attempts to gracefully fail; if it can't gracefully fail, the user usually sees instructions to save what progress they have and log out.

Is this belt-and-suspenders? Yes. Do I like having to do this? No. Has it saved my sanity, sleep time, and bacon on many many occasions?

Yes. Oh, yes...

So, if you have a "hostile" programming environment where you can't always trust the data that's being fed to your code, it's reasonable to embed all kinds of sanity checks...go full belt-and-suspenders, all the way.

Otherwise, it's not needed.