… 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 Marije Brummel 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.
Thanx guys for taken up the challenge I did throw at you all and in return you did challenge me.
As my colleague said: Hey, you wanted a discussion and you got one!
There's more to my statement than simply the text above. I deliberately did not dwell on that to make it clear and challenging.
@Generic: if that makes it stupid so be it.
BTW: on your mibuso post you state that my “blog didn’t even mention his reason for not validating”. True, but the reasoning is to be found in my Validating Data series. Did you read it all?
As I state there that using VALIDATE should be done SMART which relates to having “a good reason for it”.
@Marco: indeed “you have to wonder "is this the right way of doing this".”
Irrespective of being a senior or junior developer.
@David: I understand your concern that “there will be beginners reading it”. But they will also be reading all these comments. They (hopefully) will also be reading my Validating Data series and they have to learn to become senior developers. Just as with growing children you cannot guard them from (every) danger and in some way have to expose them to it.
BTW: I am not sure if “Navision always taught in its classes” is a valid argument for not taking the “backwards” perspective. In my Navision Solution Developer classes I took the “backwards” perspective as I found out that too often VALIDATEs were used thoughtlessly. The same applied to the code “me and my colleague were investigating”, as I wrote above.
@Kriki: I am glad I had to wait with my reaction (too busy up till today) because your input is a valid addition to all the others. And yes, it is a good approach mimicking the user’s behavior as a start. However if the code has to be operated on thousands of lines batch-wise we have to make sure that our code is more efficient than this user.
@Kine: you state that you need to choose between a ”stable application with overhead, or optimized application with bigger risk of mistake with each new change and possible "ghost" errors.”
@Cristina: likewise Kine you state: “I think the benefits on performance do not compensate the risks in consistency now and on the future.”
Makes full sense, but I would like my developers to do both.
Probably due to my age having been raised as a developer in the era where CPU time was very restricted and you had to design, write and test your code using paper and pencil only before you would go and type it into the computer.
@Alex: sure “VALIDATE is the most direct way to validate the business logic in the system.” I cannot but agree in that and it has to be used that “a good reason”. But it does not mean that you have to code a VALIDATE on every field. Be SMART.
And then it all comes to psychology it seems. What rule-of-thumb makes a better appeal to the brains of a developer?
Or
Apparently we differ in our conclusions.
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.
Good to hear as that's what it's exactly for.
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.