- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- 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
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.
Admin
Extracting and eliminating egregious exceptions to an erstwhile efficient encoding is essentially exemplified by eurgh, you get my drift
Admin
The author of the code (not the submitter) has a mind which is fundamentally incompatible with software engineering.
Admin
@Prime Mover:
Yeah, I tried the E- alliteration too and didn't get nearly as far as you did before frustratedly failing. ;)
Admin
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.
Admin
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?
Admin
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.
Admin
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)Admin
... 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.
Admin
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")
Admin
Great point! And don't forget i18n!
Admin
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.
Admin
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...
Admin
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!
Admin
You have a database. Add a "human readable" field in the database. Pull that. Ffs...
Admin
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.)
Admin
(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)
Admin
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.
([A-Z][a-z]+)
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.