Quote Originally Posted by jmcilhinney View Post
That's part of what commenting is about: things seem obvious to you when you write them so you don't comment them but they may not seem obvious to others or even yourself some time later. I'm sure everyone has written what they thought was obvious code at the time and has then come back later and wondered what it was all about.
This is what ALL my commenting is about. The number of times I have come back to what I thought was perfectly clear only to find it much less so is disturbingly high. I've tried to improve the quality of my comments, but to some extent I find that to be a fools game. You can never be certain what perspective the new viewer will come from, even if that new viewer is a later version of yourself. Therefore, it is nearly impossible to know what comment will be the key point that will crystalize understanding in the brain of the new viewer. Worse, writing too much is often as bad as writing too little, as it can be hard to wade through, so you can't write absolutely everything. This is a point I constantly wrestle with.


@EG: I found that it did not capture the intent very well at all. Though I generally know what .Any does, I was a bit surprised to find that I wasn't sure what it meant in that particular case for a fraction of a second. Count > 0 is actually more clear to me than .Any, though I see no particular reason why that would be so, which suggests it is more due to the peculiarities of the individual or individual experience. Nonetheless, it is so.

However, would you write slow code rather than fast simply because it is easier to read? That would be an argument for implicit conversions and option Strict OFF. After all, if you can be certain that a certain string holds a number, then MyString = 5 is considerably more readable than CInt(MyString) = 5, or any other proper conversion. Anybody can read the first variation without problem, but somebody new to programming would likely be unsure what CInt(MyString) was doing in the second variation. Option strict does prevent certain bugs from slipping in, but probably not bugs that you would allow anyways.

Furthermore, if you are in the habit of reaching for the slower tool because it looks better to you, wouldn't you expect that performance is more likely to be an issue than it would for a person who is in the habit of reaching for the fastest tool? A fraction of a millisecond here and there usually makes no difference at all, until you end up working on a program where it does matter and you have to go back and re-work it because you neglected to do so on the first pass. In this case, I feel that .Any is less clear than .Count >0, but that's just a matter of opinion. Still, knowing that there is a difference of opinion there (and I'm clearly not alone in my view, since we aren't talking about code I initially wrote), wouldn't it be better to reach for the tool that works better?