• WTFGuy (unregistered)

    Relying on routine regularity regularly rears rare and repair-resistant regressions resulting in regurgitated 'rror reports wrongfully rendered remotely, resulting in red-faced recognition of rampant runaway records rapidly retained by Russian rogues.

  • Prime Mover (unregistered) in reply to WTFGuy

    Extracting and eliminating egregious exceptions to an erstwhile efficient encoding is essentially exemplified by eurgh, you get my drift

  • (nodebb)

    The author of the code (not the submitter) has a mind which is fundamentally incompatible with software engineering.

  • WTFGuy (unregistered)

    @Prime Mover:

    Yeah, I tried the E- alliteration too and didn't get nearly as far as you did before frustratedly failing. ;)

  • (nodebb)

    The alternate strategies of either listing all options, or applying logic to make a transformation, each have pros and cons. It's a trade-off which one you want to deal with.

    Either way though, listing these as an infinite if/else is the real WTF.

  • (nodebb) in reply to Mr. TA

    Not to surprising. In Engineering environments, everybody who ever had programming in their curriculum could be thrown at programming tasks, that also require domain knowledge.

    Probably the same in other fields.

    As they like to say: How hard can it be?

  • DrPepper (unregistered)

    Suppose you saw this pattern and said "looks like a pattern, lets replace this monstrosity with code that splits the field names into human readable strings with spaces."

    Now you've introduced a rule about how field names are named; which is created in this one method, in a likely obtuse fashion (i.e., regular expressions). A developer who is not intimately familiar with this method may choose a perfectly good field name for his use case, but which does not follow these rules.

    Introducing a bug in the UI (visible to the user) because a developer chose a field name (an internal implementation detail) should never happen.

    So while this code example is hard to read, it at least decouples internal implementation details from those details visible to the user.

  • cellocgw (unregistered)

    I know! I know! Let's assign TWO name to each object, each name being a single word. Then the human readable version is simplly

     sprintf('%d %d', Name1, Name2)

  • Yikes (unregistered) in reply to Mr. TA

    ... or someone coding without being given a standard / ICD. If you can't be sure that the field follows a pattern, should you code to it? Then again, there's still room to criticize: creating a set() of the strings that fit the pattern and checking to see if the string to convert belongs to it would be O(1) instead of O(n), with n being the number of strings fitting that pattern. That lets you have your cake and eat the exceptions too.

  • Yikes (unregistered)

    Ye of little RE faith! You could still handle weird, acronym-style exceptions using regular expressions. You just need to add space before every [A-Z][a-z]+ instead of every [A-Z] (that's not at the beginning), that way something like NormalisedTCPViewer still becomes "Normalized TCP Viewer" (yes, I snuck in an extra RE to convert "ise" -> "ize")

  • (nodebb) in reply to DrPepper

    Great point! And don't forget i18n!

  • YetAnotherDev (unregistered)

    Whilst there are better ways to writing a mapping function, I don't really agree this is such a bad WTF. Field-name is a likely a database (or other source) field, whilst the output of the function is meant to be human readable.

    A far-worse WTF is to transform-and-render the database field name to the user. Having a mapping function allows for a complete disconnect between the database names and UI naming. Otherwise, a minor update to the UI (e.g. to change the "My Stuff" field to "Customer Count") becomes a change to the database table including and all stored proc, views, ODM mappers etc. Plus, mapping functions allow for localisation.

  • Wizofaus (unregistered)

    Most of us have written code that takes an enum and automatically converts it to a somewhat human readable representation, but it really does only have limited use cases, where the expected lifetime of the project is short and intended viewers of said representations be English speakers etc. Using the enum name to lookup a localisation table is nearly always a better bet even if the English version looks like a lot of redundancy. What would be nice is a tool that caused failures at compilation time if any of the mappings were missing...

  • Worf (unregistered)

    It's too bad when using stringly-typed enums, that you absolutely cannot use strings that are already human readable. I mean, "ProductCategory" works fine as a stringly-typed enum, but heaven help you if you dare try to use "Product Category" instead. Spaces - the horror!

  • Junkfoodjunkie (unregistered)

    You have a database. Add a "human readable" field in the database. Pull that. Ffs...

  • (nodebb) in reply to Yikes

    Hmm. It's still not that simple because of silliness like, say, WiFi (commonly written that way) which we don't want to be normalised as "Wi Fi".

    By the time you've hunted all the weird edge cases, it's going to end up simpler to ... um ... well, ...

    Just put a second (...) column or a special (...) table to provide a translation between the stringly-typed enum values and their presentation format representation. (That also makes localisation easier, ffs.)

  • verisimilidude (unregistered)

    (not sure how this Python snippit will render but I'll try) def xform_to_presentation(name): if name in exception_xforms_dict: return exception_xform_dict[name]; return default_xform(name)

  • Airdrik (unregistered)
    Comment held for moderation.
  • aalien (unregistered) in reply to WTFGuy
    Comment held for moderation.
  • (nodebb) in reply to Yikes

    Yikes is very close, but it doesn't put a space between Normalized and TCP. I used Regexstorm (. net) to test and what worked for me was.


    Replace with: " $1 " (spaces before AND after back reference, quotes are just here to make the spaces apparent) That will put spaces at the beginning and end of the result, but a quick Trim() pass fixes that.

  • Officer Johnny Holzkopf (unregistered) in reply to Worf
    Comment held for moderation.
  • ram shah (unregistered)
    Comment held for moderation.
  • gun center (unregistered)
    Comment held for moderation.
  • alpha delta (unregistered)
    Comment held for moderation.

Leave a comment on “Capital Irregularities”

Log In or post as a guest

Replying to comment #:

« Return to Article