Hi Herfried,
|| Better: 'If Not Regex.Match(...).Success Then...'.
Ha ha, here's another of those how do you do it situations.
I did consider:
If Not re.Match (Str(I), Patt).Success Then
'Not a match.
End If
which reads as better English. But I changed it to
If re.Match (Str(I), Patt).Success = False Then
'Not a match.
End If
as you saw in my post. My reasoning has to do with the way that people
read (scan the code) and my understanding of perception, blah, blah, etc, etc.
It's based on the assumption that people are lazy/hasty/unmethodical - call it
what you will - but essentially that it means that there's a chance that they
won't see things (the code) properly and will form an understanding based on a
quick glance.
So if someone looks at the If statement and focuses on the "Success Then"
part, they will think that the test is for a successful match. Not everyone
will do this, of course, and you'd hope that most programmers were capable of
scanning a complete If statement. However I cater, in these instances, to the
weaknesses of man, not the ideal.
I pride myself on being a capable programmer but I have (in the past) been
caught out by this myself on any number of occasions. Sometimes it's been when
I was tired, perhaps after programming for a long period, or at times when my
concentration was been on a different aspect and my brain was in a hurry for
me. Plenty of reasons. I reckon that if I can do it, with all my carefullness,
then a defensive coding style can help prevent it.
To understand
If Not re.Match (Str(I), Patt).Success Then
you have to scan the whole expression and then negate it. You can't (to
me) understand it at a glance. And you musn't miss the 'Not'.
To understand
If re.Match (Str(I), Patt).Success = False Then
you can notice the negation of success at a glance. It's practically
impossible to see the 'Success' and miss the 'False'.
I use the same logic with multi-line statements (more the case in C# than
VB).
If Walls.Coating = Slime.Oozing And _
PeopleInTheBuilding = Nobody Then
Call GhostBusters
End If
isn't as good for at-a-glance scanning as
If Walls.Coating = Slime.Oozing _
And PeopleInTheBuilding = Nobody Then
Call GhostBusters
End If
for in the first case, failing to scan the ends of the lines correctly
means missing the And and the Then and thinking that PeopleInTheBuilding =
Nobody is an assignment.
In the second case there is no ambiguity because statements cannot start
with And.
It's all very subtle and highly debatable. But I'm partly a psychologist
and I study mistakes (mostly my own - plenty of raw material and I can
investigate contributing factors more easily). This is what experience has
shown me.
Finding anyone else who'll agree? Ha, ha.
. It's too minor and trivial
for most programmers.
Regards,
Fergus.