• Debra (unregistered)

    "H" and "O" are uppercase - because reasons, obviously.

  • LinAGKar (unregistered)

    I see no huge problem with setting the enum values the match ASCII letters. TRWTF is redefining the whole alphabet as an enum instead of using char literals.

  • LookingForAJob (unregistered) in reply to Debra

    They aren't uppercase, they are randomcase like the other names. Visual Basic 6 fixes the case for you and does a shitty job. Experienced VB6 programmers have case insensitive eyes.

  • DQ (unregistered)

    I fail to see the use of this. Do they want to write something like

    Status = s

    in stead of

    Status = Shipped

    because that is so much clearer.

  • Naomi (unregistered)

    Ah yes, the enum. It's a convenient way to give an integer a discrete domain of values, without having to worry about constants. But you see, therein lies the problem. What happens if you don't want to use an integer? Perhaps you'd like to use a string? Or a datetime? Or a char? If that were the case, some might say just make a class that acts similarly, or then you clearly don't want an enum.

    Trivia time! In Java at least, an enum is a class. In one of my projects, I've got an enum that implements Predicate to provide a JSON-friendly representation of the always-true and always-false predicates. The standard library actually uses this to give you a Set implementation backed by a bitfield (okay, backed by a bitfield if the enum has 64 or fewer elements, anyway).

    ...well I think it's neat, anyway!

  • MiserableOldGit (unregistered)

    Is it wrapping/screen-scraping some old greenscreen type system no-one wants to modify and those end up as sendkeys? Still a WTF, but at least one with some sort of point to it.

  • Hanneman (unregistered)

    VB6 is case preserve. With a Dim wHaTtheHEck it will keep that case from the highest declared variable even if you try to do a new Dim (local variable?) elsewhere Case sensitivity in computer languages is at the same level as NULL. Case preservation it should be!

  • mihi (unregistered)

    I like that in Java you can define member variables inside your enum and then have each enum option assign values to them.

    So you still have normal ordinal enums, can iterate over all of them easily, but still can convert them to a char or string for storing into database ('u' is a lot more readable in a database dump than 4) or back.

  • Foo AKA Fooo (unregistered) in reply to Hanneman

    So if you have a global variable "GotHere", you cannot have an unrelated local variable called "GoThere"? Yeah, that's totally not a WTF!

  • Klimax (unregistered) in reply to Foo AKA Fooo

    That's WTF too. Perfectly confusing.

  • Sole Purpose of Visit (unregistered) in reply to LinAGKar

    That's because you've never worked in a loosely-typed language (VB.Net springs to mind) where the call site "knows" that the enum is actually a random collection of English-specific characters and makes use of that "knowledge" by switching on ASCII characters, because "it's all the same thing, innit?"

    No.

    No, it int.

    And I have the scars to prove it.

  • Hanneman (unregistered)

    Many bugs are caused by to little lexical distance between variable names. Your's a perfect example.

  • Hanneman (unregistered) in reply to Hanneman

    Was meant as reply to Foo AKA Fooo

  • Anonymous Beaver (unregistered) in reply to Hanneman

    Many examples of misunderstanding are caused by bad grammar. Yours is a perfect example!

    (Sorry about this, I just had to say it)

  • Hanneman (unregistered) in reply to Anonymous Beaver

    :-) Probably correct, but for a non native English speaker not too bad ...

  • Foo AKA Fooo (unregistered) in reply to Hanneman

    Nope. "GoHere" is closer to "GotHere" than "GoThere" is, yet it works fine. If you want warnings on close name matches, implement that instead of relying on case-insensitivity catching just a few random cases.

  • Naomi (unregistered)

    Consistent capitalization helps readability, and case sensitivity is an easy way to enforce it.

  • Say what (unregistered)

    This isn't a WTF - it's pretty smart. You have a set of existing status codes (E, S, U, etc). Each one means something. Additionally, you need to convert to and from the meaning frequently, and you cannot screw up that conversion because things will break badly. How do you make sure that in your CODE, you can use the MEANING, but in your real-world-printed-STATUS, you never mistranslate? You could do a custom function to make sure that you don't get it wrong, but then some gimp will probably forget to use it. OR you could make sure that it maps EXACTLY to the correct character, thus ensuring that the meaning and the real-world-character are always 100% synchronized - and ALSO ensuring that no programmer is able to add in another "meaning" constant without being aware of whether they're overloading an existing status code. This isn't a WTF, it's actually brilliant.

    (Yes, you could do it in another way, yes, this is "abuse" of enums, blah blah blah. There can be a fine line between "abuse" and "elegant use of existing functionality" - see Duff's Device, for example, or MANY of the hacks used in game programming. How 'bout you take your enterprise coding standards and shove them where the sun don't shine, eh?)

  • jgh (unregistered) in reply to Hanneman

    That would be non-native. "non" is not a word.

Leave a comment on “Classic WTF: A Char'd Enum”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article