• WTFGuy (unregistered)

    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 */

  • Hanzito (unregistered)

    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?

  • nesadi (unregistered)

    The wtf begins where apparently in Visual Basic, the "and" operator functions as the boolean logical "and" as well as the bitwise "and".

  • Sauron (unregistered)

    Yes to All WTF!

  • Watson (unregistered) in reply to nesadi

    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...

  • Tinkle (unregistered)

    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.

  • Deeseearr (unregistered)

    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?!!!!!!!"

  • WTFGuy (unregistered)

    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...

    Nope. The AndAlso and OrElse are short circuiting boolean operators. And and Or 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

  • RequiredName (unregistered) in reply to Watson

    But quite some programmers don't know the difference and use the former in both conditions... << From the documentation I read (e.g. https://learn.microsoft.com/en-us/dotnet/visual-basic/language-reference/operators/and-operator), And/Or are Boolean and bitwise operators, as nesadi stated. The AndAlso/OrElse are short-circuiting Boolean operators. However, I didn't know about AndAlso/OrElse so I have learned something from this experience.

  • Watson (unregistered) in reply to WTFGuy

    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

  • (nodebb)

    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.

  • (nodebb)

    Clearly this code was improvised, and the author was therefore applying the improv principle of "yes, and".

  • Duke of New York (unregistered)

    "I said it was readable, not meaningful."

  • (nodebb)

    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.

  • (nodebb)

    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#.

  • Confucius (unregistered) in reply to Watson

    I didn't know this. I have been bitiwsing for years when I wanted to boolean.

  • Tinkle (unregistered)
    Comment held for moderation.
  • (nodebb) in reply to Watson

    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.

  • WTFGuy (unregistered)

    @Watson Ref

    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.

    You probably weren't writing VB.Net back before AndAlso and OrElse were added to the language. They were not present in the early versions of VB.Net.

  • (nodebb) in reply to prueg

    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.

    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".

  • (nodebb) in reply to Scarlet_Manuka

    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.

Leave a comment on “Easy Reader Version”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article