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

A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station....
_________________________________________________________
My programs never have bugs, they just develop random features.

A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station....
_________________________________________________________
My programs never have bugs, they just develop random features.

A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station....
_________________________________________________________
My programs never have bugs, they just develop random features.

I have a singleton data cache I'm working with.
I was testing whether or not the cache items were removing correctly from a consumer of the data.
I was checking via a different object in the debugger that would pull the object in question from the cache.
The problem: This different object creates the bloody cache item if it doesn't exist, but in the debugger it just looked like it wasn't deleting. My code was fine all along... The brain fart was in the debugging... Double

Debugger based testing is fundamentally limited by the lack of repeatability intrinsic in having a human poking around during the session, whereas automated tests to do the same thing should (if designed correctly) be absolutely repeatable.

As a bonus the tests stick around long after the debug session is ancient history. If someone breaks the code several years from now, the tests will start failing to alert you to that fact.

"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"

When I first started in a Microsoft position, I asked why they were renaming procedures that were basically doing the same thing. It was their control method, the old procedures retained old behavior, the new code expected new behavior. After the new was promoted to production, the old was removed from SQL. If the lab started squaking, they knew they missed something.

Sure missed that on a later project. About 80% of the existing tests were failing because the sprocs were massively changed and no-one bothered to maintain the tests when they re-wrote the sprocs.

A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station....
_________________________________________________________
My programs never have bugs, they just develop random features.

A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station....
_________________________________________________________
My programs never have bugs, they just develop random features.

Looks like someone was planning on getting a string feed and forgot to feed the string or forgot to stop destroying the string.
So what did you do to refactor it? Change code to x=0;y=0;z=0;? And keep _xyz = "0 , 0 , 0";? Remove _xyz = "0 , 0 , 0"; and verify the split causes at least 3 parts? Add error checking on the tryparses? Remove XYZ and all references?

I got rid of the '_xyz' string, it was only used internally (in addition to x,y,z double) and parse every now and then, to get the value of 'x,y,z'

A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station....
_________________________________________________________
My programs never have bugs, they just develop random features.

A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station....
_________________________________________________________
My programs never have bugs, they just develop random features.

Assuming this is a SQL Server connection, I don't think you can lay this directly at SQL's door, but you might want to see if triggers are involved and see what they do on insert/update. Maybe the update trigger on the child will insert the parentID in the parent table if it doesn't exist?

No, that doesn't make sense, the update should fail with a foreign key constraint failure before it reaches the trigger.

No. The table is created by EF Code First, nothing but the table itself. Not even indexes but for the PK. I think it's something to do with EF trying to also save another child of the same parent, and clashing somewhere far away.