- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
I'm going to get even for the time that other dev was mean to me in a group meeting and criticized my perfect coding style. I'll show him who's the greater coder!. Neener neener!!!1!1!!. AND Windows.Forms.DialogResult.ScrewYou /* Tee hee */
Admin
I guess the intention is that "Yes to All" is a combination of Yes, and a kind of Ignore-the-rest-of-the-confirmations. The insight that you must therefore Yes to All Retry, because the bitwise and of two button codes maps onto that, is almost mystic. So: divinable at best, but readable?
Admin
The wtf begins where apparently in Visual Basic, the "and" operator functions as the boolean logical "and" as well as the bitwise "and".
Admin
Yes to All WTF!
Admin
Not quite, the bitwise operators in VB.net are "And" and "Or". The boolean operators are "AndAlso" and "OrElse". But quite some programmers don't know the difference and use the former in both conditions...
Admin
No FILE_NOT_FOUND in that enumeration?
@Hanzito VB has the AndAlso operator which does the && version. Using 'and' for logical and boolean and is not too bad, as numbers can not be used as booleans in VB.
Admin
I think I saw that movie before...
"Well, look, I already told you. I deal with the damn return values so the calling functions don't have to!! I have readability skills!! This code is readable!!! Can't you understand that?!? WHAT THE HELL IS WRONG WITH YOU PEOPLE?!!!!!!!"
Admin
Nope. The
AndAlso
andOrElse
are short circuiting boolean operators.And
andOr
are both bitwise operators and boolean operators depending on context.See https://learn.microsoft.com/en-us/dotnet/visual-basic/programming-guide/language-features/operators-and-expressions/logical-and-bitwise-operators
Admin
Admin
You're reight indeed, you can use them as boolean/logical operators (conceptually, boolean operations are bitwise operations on a 1-bit-value). Although I never used them that way, nor can i think of a useful application at the moment to use them as logical operators instead of the short-circuiting ones which doesn't reek like code smell.
However, they are 1:1 equivalents of the C# operators "&" (And), "|" (Or), "&&" (AndAlso), "||" (OrElse). Therefore if you wtf them in VB, you have to wtf them in C#, Java, C++, ... aswell.
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/operators/boolean-logical-operators
Admin
Ha, it's so funny, I have seen soo many times already mistakes when it comes to boolean operations. In the old days it was usually an oversight (I fall into those traps as well especially for more complex conditions) but these days most of the time it's because the dev has no idea how it works. You might think that literally two states should be the least complex and easiest to understand system there is, but nope, simple operations like exclusive or are now super mythical magic things.
Admin
Clearly this code was improvised, and the author was therefore applying the improv principle of "yes, and".
Admin
"I said it was readable, not meaningful."
Admin
This sounds like a developer was told off for using magic numbers like "4", for not being easy to read. They argued "but that's the value of Retry", and were told that wasn't good enough. Being confused about the whole thing, they interpreted that to mean that simply substituting "4" for "Retry" would not be a sufficient fix, and came up with this stupidity.
Admin
So if they'd written
Windows.Forms.DialogResult.Yes + Windows.Forms.DialogResult.Continue
they'd have a value to represent "Yes to All" that doesn't collide with an existing value in the Enum, right? VB Enums are just as happy to have values that don't correspond to Enum values as C#.Admin
I didn't know this. I have been bitiwsing for years when I wanted to boolean.
Admin
Thinking about this a little more, the way to make it readable would be to use a constant called YesToAll. What value to use for that though...
Admin
Technically you can assign any underlying type value to an enum and it will be fine even if they enum isn't marked as [Flags]. Proper enums are just value types and intentional lightweight, because the point to have named integers. The dev is therefore responsible to handle them correctly.
Admin
@Watson Ref
You probably weren't writing VB.Net back before
AndAlso
andOrElse
were added to the language. They were not present in the early versions of VB.Net.Admin
I thought it might have been that they used Windows.Forms.DialogResult.Retry and then got told off because it didn't make sense that "Retry" meant "Yes to All", so they had to rewrite it in a way that used Windows.Forms.DialogResult.Yes to make it "make sense".
Admin
Building on responses from Hanzito, prueg, and Scarlet_Manuka, I wonder if we can piece together a complete scenario:
Originally the developer was using the magic number 4 to represent "Yes to all". And they built out the system with that understanding: across the codebase, 4 was understood to mean "Yes to all".
But then later on, they were told, or possibly identified on their own, that magic values were a problem (as prueg suggests) and their code would be more readable if they used the Windows.Forms.DialogResult enum.
But the problem is that that enum doesn't have an entry for "Yes to all". It has "Yes" but not "Yes to all".
So the next question became, how to represent "Yes to all" in an enum that doesn't contain it. Fortunately, they knew about bitwise operations, and how efficient they were, and they recognised that this problem could be solved: they could incorporate Windows.Forms.DialogResult.Yes (as Scarlet_Manuka suggests), while still using the number 4. They could even do it in a way that made some sort of sideways sense (as Hanzito suggests), by combining Yes with Ignore.
Because they weren't changing the value itself, but only the way it was displayed in the source code, the change was very low risk. Once the developer confirmed that "Windows.Forms.DialogResult.Yes And Windows.Forms.DialogResult.Ignore" really did produce the number 4 as expected, they didn't need to worry about introducing regression issues. All that was left was to make sure it was clearly documented.
Hence the comment, in every place this unusual piece of code was used. We're trying to create the value 4 out of something that includes "Windows.Forms.DialogResult.Yes", and that's what we've done, using those efficient bitwise operations. We know that we could have used "DialogResult.Retry" to represent 4, but that wouldn't have made sense.
It's very elegant, really. If there were no better ways to solve this problem, then this would have been the best solution.