The Weird and The Wonderful

The Weird and The Wonderful forum is a place to post Coding Horrors,
Worst Practices, and the occasional flash of brilliance.

We all come across code that simply boggles the mind. Lazy kludges, embarrasing mistakes, horrid
workarounds and developers just not quite getting it. And then somedays we come across - or write -
the truly sublime.

Post your Best, your worst, and your most interesting. But please - no
programming questions . This forum is purely for amusement and discussions on code snippets. All
actual programming questions will be removed.

Yes: [Email] will always be an empty string, not null (except when ISNULL evaluates NULL as something different from NULL). String.Empty and NULL is an enormous difference for MS SQLServer and most (or all?) object-oriented programming languages. But not for zen-lacking Oracle.

Honestly this was probably done in haste and without care for proper coding as part of a set of replacements in the stored proc of the "Email" field with NULL. Things do happen fast and furious around here and there is no dba to oversee/filter.

I found it humorous enough to share with those who like to smack themselves in the forehead

And the enumDictionary is just declared Dictionary with (string, enumType) pairs
The names are changed.
This beautiful thing is written in c# from someone else than me, a colleague who worked longer than me in the firm. He is working mainly with c# projects i am working mainly with vc++ and MFC(oh the joy) When i have to change something my boss always says to me to write it in the same manner like the things are done in the project.
The worst part is this gem is written in my dll (the dll i should be working but all other are adding things but me)
I hate when someone else is touching my code.

Why use a Boolean when a string comparison, case conversion and check for null string will do?
Why is that Boolean argument optional, when it is always supplied?

(before someone says, predictably, that the real WTF is VB, I'd like to point out I've seen code just as horrible in most languages.
The real real WTF is that people who produce such garbage are still employed.

"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.

Well spotted - I left that one deliberately to ensure folk are paying attention

Actually, most of the real horrors in this particular code base are more subtle and hard to illustrate in short snippets and more to do with putting too much business logic in event handlers for controls. When a form loads, info from the database is written to a control, which fires an event handler, which writes to another control, which fires an event handler, which... I think you get the picture. Business logic is totally interspersed with UI logic - often broken out into separate modules the contents of which have no logical relation. Global variables are used for all sorts of purposes. "Option Strict" has not been used, and frequently variables are not declared anywhere at all... GoTo's and even GoSub's are used liberally.

I'm just glad I'm tasked with rewriting it rather than maintaining it, but it can be software archaeology trying to determine what the heck the original logic was intended to accomplish.

"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.