Actually, I like != (or even ?=) better than <>. It's so much more
difficult to say less-greater than not-equal.
In fact, now I think about it, doesn't <> come from BASIC? Isn't it
more or less exclusive to BASIC and RPG?
For better readability, I have functions that look like Visual Basic,
because my old eyes sometimes do not see the symbols = and <> all that
well. But I do see IsNotBlank( ) and IsBlank( ) and IsNotZero( ) and
IsZero( ) much better, and these constructs also read more like English.
Yes, there is an inefficiency of function calls, but the meaning is so
much cleaner, and my code can be run through an RSpec "English-izer" to
support Requirement Reviews.
Also, getting back to the file accessor methods Brian May and Kurt
Anderson use, most of the "Is it blank?" we are asking is really "Was
the field entered, is it a key entity, and is it a valid key?" which is
an abstraction of Domain Driven Design.
In some future world, I hope to improve or override my IsNotBlank()
functions that I create today to be "Entity-Key Aware". Hopefully,
with V.7 and a nice generic file accessor method, we could write
DDD-type functions that are really
IsEntityKey( ScreenField ) type functions that would know the synonym or
attribute of "ScreenField",
and know that it is a key field, and validate it to it's master file
quickly, and also log any accompanying error message into the
interactive message queue for a generic message routine connected to the
display to pull out. Knowledge of this sort within a function should
also support behavior like if the field is blank, then automatically
show a prompt screen to the user for this required key.
midrange.com
