If you read Validating Data #3: Cascading VALIDATEs you know by now that a VALIDATE call comes with a price. So where possible the programmer should diminish the number of VALIDATE calls. Or "... to avoid the validate statement when populating records ...", as Marq puts it in one of his posts.
Sure, I know, if you need to impose business logic on code entered data you need to validate the value assigned. But that's something different than by default always program a VALIDATE statement to assign a value, "... just to be sure ...", as I recall some of my students said.
Not too long ago I was debugging some code that involved the creation of some kind of journal line. For every field a VALIDATE was programmed to populate - and validate - it. The darn bug I was trying to reproduce and find a fix for, was founded in this simple 'listing' of VALIDATES. One VALIDATE was assigning and validating some item related field while a next one was, indirectly, refreshing it based on an Item.GET statement. So this "... just to be sure ..." was not only triggering probably a lot of unneeded and duplicate validation code, it was also frustrating a previous action.
Would it be possible to phrase some general rules on when to use a VALIDATE and when not? Let me give it a try and maybe you could provide some additional ones.
... but be smart!
You are too good!