Never Use VALIDATE ...

... unless your have a good reason for it!

Already a year ago I wrote my Validating Data series. And only a couple of weeks ago me and my colleague were investigating one of our solutions that had a performance issue and were faced with code that wasn't quite SMART with respect to using VALIDATEs. If you're not sure what I am referring to (re)read this post: Validating Data #4: Assignment and VALIDATE.

Rule-of-Thumb vs. Rule-of-Thumb

And there we were sitting.  Me wondering how an intelligent developer could have done this. My colleague (not his code; not mine either) wondering what actually was wrong about it. As became clear we both were looking from a very different perspective at these lines of code where a number of fields were populated and validated at the same time.

My perspective based on the rule-of-thumb saying: Never use VALIDATE ... unless you have a (very) good reason for it. Or, quoting Marq in my post, "... to avoid the validate statement when populating records ...".

My colleagues rule-of-thumb: always validate a field when assigning a value, because you're never sure validation code is behind it.

I (still) think I could make my point and could clarify that his rule-of-thumb is definitely not a good enough reason to use VALIDATEs. So I would like to stress to you all again:

Never use VALIDATE ...

... unless you have a good reason for it.

If you're not sure what I mean or disagree. Read my Validating Data series and challenge me below.

BTW ...

... dimishing the number of VALIDATE statement in our code did help, but (unfortunately) wasn't the main problem.

Update 2011-01-30

After you did read this post be sure to read the comments below as I wrote it because of the discussion. And of course, if you did not read my Validating Data series yet take your time for it.

Anonymous
  • Hi Michael,

    Thanx for the comment, and agree in essence. However I have a question as I think I am missing the point in the example you use.

    Why assing a value to the amount after the VALIDATE? In this way the validation does not use the amount value you are going to set.

  • Regardless of what school of thought an individual chooses to go with, I think there's another lesson to be learned:  Pay attention to the order of your assignments and validations.

    Luc provides the following code in Validating Data #3:

    GenJnlLine.Amount := Amnt_from_Import_Line;

    GenJnlLine.VALIDATE("Account No.", AccntNo_from_Import_Line);

    How detrimental would it be if we were to write the following instead?

    GenJnlLine.VALIDATE("Account No.", AccntNo_from_Import_Line);

    GenJnlLine.Amount := Amnt_from_Import_Line;

    We need to make sure our code is sorted in such a way to maximize the efficiency AND safety.  Paraphrasing something that Daniel Rimmelzwaan said in a different post, it often comes to "a series of strategically placed VALIDATE statements."

    Maybe I'm being very elementary and obvious, but too often I see people's first reaction is to fill in the record's fields from left to right.

  • Good to hear as that's what it's exactly for.

  • I appreciate this blog post since it has given me a valuable discussion about pros & cons about using validation!

  • Sounds stupid, but there was something this morning saying: "you're forgetting something". Apparently you hit it, Thomas. Thanx.

    You say this isn't "a topic for a rule-of-thumb at all" and that makes sense. So why my rule of thumb? Because I have come across a lot of developers that used the '"forward" rule-of-thumb, being the "always validate a field when assigning a value, because you're never sure validation code is behind it". Using it thoughtlessly.

    My rule, the "backwards" one, is opposing, raising the discussion here, but also (hopefully) raising awareness on the fact that you shouldn't just use a validate base on the "forward" rule.

    Be SMART and, indeed, read the dos and don'ts.

Related
Recommended