Bugs in the funniest of places
-
I built out a lexer and half baked parser to scan a C header and produce a CSV with certain data pulled out of it. I got the lexing and parsing of the header done in no time, and with a minimum of fuss. But outputting the CSV
if (s.Key == "data_packet" || s.Key == "status_packet" || s.Key == "config_packet")
This code exists in two places. Between those two places I got this simple line wrong 3 times, and caused relatively a lot of churn w/ my colleagues in terms of their own work, which relied on this to function properly. Why sometimes its the simple parts of the code that cause the most problems I'll never know.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Because we're always so careful on the big stuff. It's tricky to begin with so more care is taken. But the small stuff, it's so simple. What can go wrong? I once made an oh so minor 2 character change to a simple program. It was so simple and so obviously correct that I just dropped it back into production. And thus tipped over an entire healthcare claims reporting system. Oops! :~
-
I built out a lexer and half baked parser to scan a C header and produce a CSV with certain data pulled out of it. I got the lexing and parsing of the header done in no time, and with a minimum of fuss. But outputting the CSV
if (s.Key == "data_packet" || s.Key == "status_packet" || s.Key == "config_packet")
This code exists in two places. Between those two places I got this simple line wrong 3 times, and caused relatively a lot of churn w/ my colleagues in terms of their own work, which relied on this to function properly. Why sometimes its the simple parts of the code that cause the most problems I'll never know.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I create my own function when dealing with these types of statements. For any number of reasons. It just compares objects.
bool ok = MyFunc.IsInList( s.key, "data_packet", "etc" ); // Uses "params" to handle a variable number of objects.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
I built out a lexer and half baked parser to scan a C header and produce a CSV with certain data pulled out of it. I got the lexing and parsing of the header done in no time, and with a minimum of fuss. But outputting the CSV
if (s.Key == "data_packet" || s.Key == "status_packet" || s.Key == "config_packet")
This code exists in two places. Between those two places I got this simple line wrong 3 times, and caused relatively a lot of churn w/ my colleagues in terms of their own work, which relied on this to function properly. Why sometimes its the simple parts of the code that cause the most problems I'll never know.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Because we're always so careful on the big stuff. It's tricky to begin with so more care is taken. But the small stuff, it's so simple. What can go wrong? I once made an oh so minor 2 character change to a simple program. It was so simple and so obviously correct that I just dropped it back into production. And thus tipped over an entire healthcare claims reporting system. Oops! :~
My favorite was, in my C++ days, putting a
;at the end of aforstatement and then spending several hours in the debugger wondering why the code in theforloop executed only once! :laugh:Latest Articles:
A Lightweight Thread Safe In-Memory Keyed Generic Cache Collection Service A Dynamic Where Implementation for Entity Framework -
I built out a lexer and half baked parser to scan a C header and produce a CSV with certain data pulled out of it. I got the lexing and parsing of the header done in no time, and with a minimum of fuss. But outputting the CSV
if (s.Key == "data_packet" || s.Key == "status_packet" || s.Key == "config_packet")
This code exists in two places. Between those two places I got this simple line wrong 3 times, and caused relatively a lot of churn w/ my colleagues in terms of their own work, which relied on this to function properly. Why sometimes its the simple parts of the code that cause the most problems I'll never know.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I built out a lexer and half baked parser to scan a C header and produce a CSV with certain data pulled out of it. I got the lexing and parsing of the header done in no time, and with a minimum of fuss. But outputting the CSV
if (s.Key == "data_packet" || s.Key == "status_packet" || s.Key == "config_packet")
This code exists in two places. Between those two places I got this simple line wrong 3 times, and caused relatively a lot of churn w/ my colleagues in terms of their own work, which relied on this to function properly. Why sometimes its the simple parts of the code that cause the most problems I'll never know.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Sometimes overthinking/overengineering something has this effect. Recently came across a piece of code which went something like this during one my code review sessions.
bool condition;
viewmodel.AllowSomething = !condition == true ? false : true;We laughed for about 30 minutes, including the guy who wrote this.
-
Sometimes overthinking/overengineering something has this effect. Recently came across a piece of code which went something like this during one my code review sessions.
bool condition;
viewmodel.AllowSomething = !condition == true ? false : true;We laughed for about 30 minutes, including the guy who wrote this.
It looks like that code evolved to be that, rather than written that way to begin with. At least I hope. I've been there. In fact, I've had code I wouldn't touch because it was like that, took forever to get right, and it worked, including handling difficult corner cases.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
It looks like that code evolved to be that, rather than written that way to begin with. At least I hope. I've been there. In fact, I've had code I wouldn't touch because it was like that, took forever to get right, and it worked, including handling difficult corner cases.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
honey the codewitch wrote:
At least I hope.
It was written that way. We laughed at it as it meant that we assign true when the condition is true and false when it's false. Just the way to go about it was really through Caradhras mountains and then through the mines of Moria.
honey the codewitch wrote:
took forever to get right
At first glance my thought was also to replace with !condition. As I missed the first ! to begin with.
-
Sometimes overthinking/overengineering something has this effect. Recently came across a piece of code which went something like this during one my code review sessions.
bool condition;
viewmodel.AllowSomething = !condition == true ? false : true;We laughed for about 30 minutes, including the guy who wrote this.
-
Sometimes overthinking/overengineering something has this effect. Recently came across a piece of code which went something like this during one my code review sessions.
bool condition;
viewmodel.AllowSomething = !condition == true ? false : true;We laughed for about 30 minutes, including the guy who wrote this.
