Comment On But...Anything Can Happen!

Every developer eventually breaks something in production. Whether by negligence, ignorance, or just plain bad luck, it happens even to the best of us. "Oops" moments like these are the ones we learn and grow from. The broken thing gets fixed, some data may or may not get cleaned up, and everybody moves on a bit for the wiser. [expand full text]
« PrevPage 1 | Page 2 | Page 3Next »

Re: But...Anything Can Happen!

2012-11-14 08:07 • by Doo-doo Facial Hair (unregistered)
I just got terrible Excel flashbacks of functions with endless =IF(something;"OK";IF(something;"LESS OK";IF(something;"HELP SOS";IF(something;"NO WAIT IT'S OK";IF(etc...

And yes I know I was using Excel for something it was not really meant for but it was the only programming tool available (read: allowed) at the time.

Re: But...Anything Can Happen!

2012-11-14 08:12 • by ACK (unregistered)
Damn, waited for years to write "First"... *Went to check my else if branch code for bugs*

Re: But...Anything Can Happen!

2012-11-14 08:12 • by Mr Magoo (unregistered)
anything can be frist

Re: But...Anything Can Happen!

2012-11-14 08:13 • by William F (unregistered)
TRWTF is the happy ending. Bad developer gets fired?

Since this is in a safety critical industry, I feel better about airplanes and self driving cars already.

CAPTCHA: ague - what I get from some of these stories

Re: But...Anything Can Happen!

2012-11-14 08:15 • by Michael P (unregistered)
Some coding standards (like, say, the ones used for C++ on the US Joint Strike Fighter program) specifically require an if/else if chain to be terminated with either an "else" handler or a comment that explains why there is no else. That seems like good practice for any software with significant safety implications.

Re: But...Anything Can Happen!

2012-11-14 08:22 • by Tom (unregistered)
394806 in reply to 394805
Michael P:
if/else if chain to be terminated with either an "else" handler or a comment that explains why there is no else
How about

else
{
alert('Universe asplode, select a different quantum fork');
}

Should be as good as the comment, if not better.

Re: But...Anything Can Happen!

2012-11-14 08:25 • by Rodnas (unregistered)
// DO NOT make changes below this comment

if (frist) {
doLameFristComment();
} else if (!frist) {
doAnythingCanHappenComment("And probably will!");
}

Re: But...Anything Can Happen!

2012-11-14 08:26 • by LoremIpsumDolorSitAmet
by creating code paths that did not assign these variables, he would cause unpredictable behavior depending on the prior values of the variables

I don't understand this. Where are these new code paths? Is he talking about the possibility of some variable being undefined and therefore the IF and the ELSE IF both eval to false and neither block is executed?

If so, TRWTF is using a loosely typed run-time language like JavaScript or PHP that allow undefined variables... especially in life-critical apps.

Or, more likely, I've been mislead by Alex's brillant editing.

Re: But...Anything Can Happen!

2012-11-14 08:37 • by Anonymous Will (unregistered)
I think he means about when some variable is supposed to be assigned a different value in the 2 branches.

Re: But...Anything Can Happen!

2012-11-14 08:41 • by Karl (unregistered)
394810 in reply to 394806
Tom:
alert('Universe asplode, select a different quantum fork');
Oh, come on! We can do better than that.

How about:

alert("Logic inconsistency error detected! After you click OK, this instance of the simulation will be terminated. You should awake in a similar universe where this never happened. In most cases people report no recollection of this event.\n\nOh by the way, if you tell anyone else, it makes timeline reintegration much more difficult. So don't do that.");

Re: But...Anything Can Happen!

2012-11-14 08:43 • by long johnson (unregistered)
394811 in reply to 394808
if patient.sick? && !patient.dead?
heal patient
else if !patient.sick? && !patient.dead?
bury patient
end

Re: But...Anything Can Happen!

2012-11-14 08:46 • by Anketam
Wow the process worked.

Re: But...Anything Can Happen!

2012-11-14 08:46 • by Justsomedudette (unregistered)
394813 in reply to 394808
LoremIpsumDolorSitAmet:

If so, TRWTF is using a loosely typed run-time language like JavaScript or PHP that allow undefined variables... especially in life-critical apps.

Or, more likely, I've been mislead by Alex's brillant editing.
That would be Mark's brilliant editing, but please don't let accuracy or spelling ruin a perfectly snide comment.

Re: But...Anything Can Happen!

2012-11-14 08:47 • by Andrew (unregistered)
You're right, anything could happen:
a = 10

Re: But...Anything Can Happen!

2012-11-14 08:47 • by TGV
394815 in reply to 394811
if patient.sick? && !patient.dead?
heal patient
else if !patient.sick? || patient.dead?
if patient.dead?
bury patient
end
end

FTFY

Re: But...Anything Can Happen!

2012-11-14 08:52 • by Herwig (unregistered)

if (a)
{
doSomething();
}
else if (!a)
{
doSomethingElse();
}
else
{
gotoTRWTF();
}

Re: But...Anything Can Happen!

2012-11-14 08:55 • by LoremIpsumDolorSitAmet
394817 in reply to 394813
Justsomedudette:
LoremIpsumDolorSitAmet:

If so, TRWTF is using a loosely typed run-time language like JavaScript or PHP that allow undefined variables... especially in life-critical apps.

Or, more likely, I've been mislead by Alex's brillant editing.
That would be Mark's brilliant editing, but please don't let accuracy or spelling ruin a perfectly snide comment.

Just because Mark submitted it doesn't mean it didn't get preprocessed by the almighty Alex! Or maybe Mark is his sockpuppet. Or maybe they're just as brillant as each other.

PS. 'brillant' is not a typo; you must be new here!

Re: But...Anything Can Happen!

2012-11-14 08:55 • by Anonymous Cow (unregistered)
394818 in reply to 394808
LoremIpsumDolorSitAmet:
I don't understand this. Where are these new code paths? Is he talking about the possibility of some variable being undefined and therefore the IF and the ELSE IF both eval to false and neither block is executed?

The issue that they're referring to would come up if they changed this:

if(a > 10)

printf("It's so big!");
else
printf("Not so big... :(");


...into this:

if(a > 10)

printf("It's so big!");
else if(a < 10)
printf("Not so big... :(");


What happens if a is 10?

Re: But...Anything Can Happen!

2012-11-14 08:56 • by masseyis (unregistered)
394819 in reply to 394802
ACK:
Damn, waited for years to write "First"... *Went to check my else if branch code for bugs*


Decades of experience in waiting to be frist

Re: But...Anything Can Happen!

2012-11-14 09:04 • by stinkiemcslimey (unregistered)
if (a)
{
dowork();
} else if (!a) {
domorework();
} else {
return(FILE_NOT_FOUND);
}

Re: But...Anything Can Happen!

2012-11-14 09:07 • by LoremIpsumDolorSitAmet
394821 in reply to 394818
Anonymous Cow:
LoremIpsumDolorSitAmet:
I don't understand this. Where are these new code paths? Is he talking about the possibility of some variable being undefined and therefore the IF and the ELSE IF both eval to false and neither block is executed?

The issue that they're referring to would come up if they changed this:

if(a > 10)

printf("It's so big!");
else
printf("Not so big... :(");


...into this:

if(a > 10)

printf("It's so big!");
else if(a < 10)
printf("Not so big... :(");


What happens if a is 10?

Yes, I understand how the terrible reverse-ifs resulted in "no fewer than ten bugs [being] created in the process".

But that doesn't help me understand "creating code paths that did not assign these variables".

Re: But...Anything Can Happen!

2012-11-14 09:09 • by Mike (unregistered)
394822 in reply to 394811
shouldn't it be
...
else if !patient.sick? || patient.dead?
...

Re: But...Anything Can Happen!

2012-11-14 09:13 • by Matthew (unregistered)
394823 in reply to 394821
int foo;

if (a > 10) {
foo = 1;
}
else if (a < 10) {
foo = 2;
}
printf("%d\n", foo); // Anything can happen

Re: But...Anything Can Happen!

2012-11-14 09:16 • by Ben Jammin (unregistered)
394824 in reply to 394822
Mike:
shouldn't it be
...
else if !patient.sick? || patient.dead?
...

...no fewer than ten bugs were created in the process.

Think about it... then giggle.

Re: But...Anything Can Happen!

2012-11-14 09:19 • by Kaso (unregistered)
394825 in reply to 394821

char* ptr;

if (something > 10) {
ptr = BIG_BUFFER;
} else if (something < 10) {
ptr = SMALL_BUFFER;
}

memcpy(ptr, source, n); //error as the code path we followed did not assign ptr

Re: But...Anything Can Happen!

2012-11-14 09:21 • by Ben Jammin (unregistered)
394826 in reply to 394822
Mike:
shouldn't it be
...
else if !patient.sick? || patient.dead?
...

Plus, if you're not sick, hopefully being buried isn't the solution. Obviously, patient.sick? needs to be a tri-state boolean of true, false, and LIFE_NOT_FOUND.

Re: But...Anything Can Happen!

2012-11-14 09:23 • by Max (unregistered)
394827 in reply to 394821
LoremIpsumDolorSitAmet:
Anonymous Cow:
LoremIpsumDolorSitAmet:
I don't understand this. Where are these new code paths? Is he talking about the possibility of some variable being undefined and therefore the IF and the ELSE IF both eval to false and neither block is executed?

The issue that they're referring to would come up if they changed this:

if(a > 10)

printf("It's so big!");
else
printf("Not so big... :(");


...into this:

if(a > 10)

printf("It's so big!");
else if(a < 10)
printf("Not so big... :(");


What happens if a is 10?

Yes, I understand how the terrible reverse-ifs resulted in "no fewer than ten bugs [being] created in the process".

But that doesn't help me understand "creating code paths that did not assign these variables".


An example in c++ would be:

float x;

if (x > 10) {

}

Defining x without initialising it to something (eg = 5.4f) means that it'll just contain the value of whatever was as that memory location. Could be any number, and results can change every time you run it.

Re: But...Anything Can Happen!

2012-11-14 09:25 • by Meta-commentator (unregistered)
Seeing a marginal WTF, expects great reams of meta commentary on the post about the failure. Meta commentary does not exisist.

So fail

Re: But...Anything Can Happen!

2012-11-14 09:27 • by Ben Jammin (unregistered)
394829 in reply to 394827
Max:
LoremIpsumDolorSitAmet:
...
Yes, I understand how the terrible reverse-ifs resulted in "no fewer than ten bugs [being] created in the process".

But that doesn't help me understand "creating code paths that did not assign these variables".


An example in c++ would be:

float x;

if (x > 10) {

}

Defining x without initialising it to something (eg = 5.4f) means that it'll just contain the value of whatever was as that memory location. Could be any number, and results can change every time you run it.

Your example breaks an if/else as well as an if/else if. Refer to Kaso's.

Re: But...Anything Can Happen!

2012-11-14 09:28 • by jonkenson (unregistered)
394830 in reply to 394821
I took that to mean that using this if - else if style would complicate things further up.

"Doug was a go-getter. He made the effort to go through the rest of the module and bring all the if/else statements into his if/else if "pattern"."

So essentially using this style, he introduced bugs higher up in the code that trickled down to cause a RWTF issue in this code.

Re: But...Anything Can Happen!

2012-11-14 09:28 • by Geoff (unregistered)
394831 in reply to 394808
Because if you convert if .. else, into if .. else if !(cond) and you screw up the !(cond) part suddenly you have code where neither the if clause nor the else clause gets executed where it would have alsways been the case at least one would have been run before.

Re: But...Anything Can Happen!

2012-11-14 09:28 • by Buffoon (unregistered)
394832 in reply to 394821
LoremIpsumDolorSitAmet:
Anonymous Cow:
LoremIpsumDolorSitAmet:
I don't understand this. Where are these new code paths? Is he talking about the possibility of some variable being undefined and therefore the IF and the ELSE IF both eval to false and neither block is executed?

The issue that they're referring to would come up if they changed this:

if(a > 10)

printf("It's so big!");
else
printf("Not so big... :(");


...into this:

if(a > 10)

printf("It's so big!");
else if(a < 10)
printf("Not so big... :(");


What happens if a is 10?

Yes, I understand how the terrible reverse-ifs resulted in "no fewer than ten bugs [being] created in the process".

But that doesn't help me understand "creating code paths that did not assign these variables".



int bar = 10;
int foo;

if(10 > bar)
foo = 10;
else if(10 < bar)
variable = -10;


Something like that spells it out enough for you?

Re: But...Anything Can Happen!

2012-11-14 09:29 • by Buffoon (unregistered)
394833 in reply to 394832
Buffoon:
LoremIpsumDolorSitAmet:
Anonymous Cow:
LoremIpsumDolorSitAmet:
I don't understand this. Where are these new code paths? Is he talking about the possibility of some variable being undefined and therefore the IF and the ELSE IF both eval to false and neither block is executed?

The issue that they're referring to would come up if they changed this:

if(a > 10)

printf("It's so big!");
else
printf("Not so big... :(");


...into this:

if(a > 10)

printf("It's so big!");
else if(a < 10)
printf("Not so big... :(");


What happens if a is 10?

Yes, I understand how the terrible reverse-ifs resulted in "no fewer than ten bugs [being] created in the process".

But that doesn't help me understand "creating code paths that did not assign these variables".



int bar = 10;
int foo;

if(10 > bar)
foo = 10;
else if(10 < bar)
foo = -10;


Something like that spells it out enough for you?


Fix...

Re: But...Anything Can Happen!

2012-11-14 09:33 • by Fred (unregistered)
Elseif can be useful. But it can ended in a mess

Re: But...Anything Can Happen!

2012-11-14 09:40 • by Abico (unregistered)
394835 in reply to 394817
LoremIpsumDolorSitAmet:
Justsomedudette:
LoremIpsumDolorSitAmet:

If so, TRWTF is using a loosely typed run-time language like JavaScript or PHP that allow undefined variables... especially in life-critical apps.

Or, more likely, I've been mislead by Alex's brillant editing.
That would be Mark's brilliant editing, but please don't let accuracy or spelling ruin a perfectly snide comment.

Just because Mark submitted it doesn't mean it didn't get preprocessed by the almighty Alex! Or maybe Mark is his sockpuppet. Or maybe they're just as brillant as each other.

PS. 'brillant' is not a typo; you must be new here!

You've been misled into thinking that was the referenced typo.

Re: But...Anything Can Happen!

2012-11-14 09:43 • by Rob Z (unregistered)
Works fine in Oracle pl/sql:

DECLARE
a BOOLEAN;
BEGIN
IF ( a )
THEN
DBMS_OUTPUT.PUT_LINE( 'true' );
ELSIF ( not a )
THEN
DBMS_OUTPUT.PUT_LINE( 'false' );
ELSE
DBMS_OUTPUT.PUT_LINE( 'null=> other universe?' );
END IF;
END;

Output: 'null=> other universe?'

Re: But...Anything Can Happen!

2012-11-14 09:45 • by TheRider (unregistered)
394837 in reply to 394826
Ben Jammin:
Mike:
shouldn't it be
...
else if !patient.sick? || patient.dead?
...

Plus, if you're not sick, hopefully being buried isn't the solution. Obviously, patient.sick? needs to be a tri-state boolean of true, false, and LIFE_NOT_FOUND.
Don't you make me spit my coffee on the screen. Too much work cleaning it...

Re: But...Anything Can Happen!

2012-11-14 09:53 • by u (unregistered)
Is doing nothing when a== 0, b >= 30 and c != null intentional? If not it somehow proves the point...

Re: But...Anything Can Happen!

2012-11-14 09:56 • by Cbuttius
the correct construct is of course to first create a boolean of the condition.

bool val = (a > 10 || b < 30 || c = null );
if( val == true )
{
do_soemthing();
}
else if ( val == false )
{
do_something_else();
}
else if ( val == fileNotFound )
{
do_anything_you_like();
}

Re: But...Anything Can Happen!

2012-11-14 10:02 • by foo (unregistered)
Reminds me of another "experienced" developer, who'd always use the mouse to select items and then do copy&paste through the context menu. Another one of those valued developers with over a decade of experience ...

Re: But...Anything Can Happen!

2012-11-14 10:04 • by Nemo (unregistered)
394842 in reply to 394826
Ben Jammin:
Mike:
shouldn't it be
...
else if !patient.sick? || patient.dead?
...

Plus, if you're not sick, hopefully being buried isn't the solution. Obviously, patient.sick? needs to be a tri-state boolean of true, false, and LIFE_JIM_BUT_NOT_AS_WE_KNOW_IT.


FTFY

Re: But...Anything Can Happen!

2012-11-14 10:09 • by foo (unregistered)
Doug adamantly refused to make the changes that Matt asked, and Matt refused to sign off to allow his development to advance.
That was when Doug threatened Matt: "Now do sign off my changes OR ELSE ... do not sign off my changes!"

Re: But...Anything Can Happen!

2012-11-14 10:14 • by allo (unregistered)
if(i++ == 1){
doSomething();
}else if(i++ == 1){
doSomethingElse();
}

Re: But...Anything Can Happen!

2012-11-14 10:15 • by Anoldhacker (unregistered)
It's probably late for this, but...

The real problem with

if (condition)
{...}
elsif (reverse_of_condition)
{...}
end

Is not that YOU might mess up your reverse_of_condition computation. We can assume that YOU are smart enough to use !(condition) for that. The real problem is that at some point condition will need to be modified. By someone who has never seen this code before. Who isn't as smart as you.

That's what "doubled the complexity" meant.

Re: But...Anything Can Happen!

2012-11-14 10:26 • by operagost
394846 in reply to 394805
Michael P:
Some coding standards (like, say, the ones used for C++ on the US Joint Strike Fighter program) specifically require an if/else if chain to be terminated with either an "else" handler or a comment that explains why there is no else. That seems like good practice for any software with significant safety implications.

Just in case of FILE_NOT_FOUND in your boolean.

Re: But...Anything Can Happen!

2012-11-14 10:31 • by chris (unregistered)
394847 in reply to 394836
Rob Z:
Works fine in Oracle pl/sql:

DECLARE
a BOOLEAN;
BEGIN
IF ( a )
THEN
DBMS_OUTPUT.PUT_LINE( 'true' );
ELSIF ( not a )
THEN
DBMS_OUTPUT.PUT_LINE( 'false' );
ELSE
DBMS_OUTPUT.PUT_LINE( 'null=> other universe?' );
END IF;
END;

Output: 'null=> other universe?'


IIRC it's the ANSI standard: null != null. Its the same in T-SQL (SQL Server) by default. One hell of an annoying convention.

Re: But...Anything Can Happen!

2012-11-14 10:39 • by TRWTFVB (unregistered)
TRWTF is that he had decades of experience in VB

Re: But...Anything Can Happen!

2012-11-14 10:55 • by iusto (unregistered)
394852 in reply to 394841
foo:
Reminds me of another "experienced" developer, who'd always use the mouse to select items and then do copy&paste through the context menu. Another one of those valued developers with over a decade of experience ...


Now you're exaggerating a little. If you had said, a guy scrolls up 2 pages of text to copy a short word so that he can paste it where he was below (to avoid typing it), then I'd understand. I noticed a couple of devs doing that for as little as 4-characters. Not to mention that IDE at the time was Visual Studio, where intellisense is present.

Re: But...Anything Can Happen!

2012-11-14 11:04 • by DB (unregistered)
394854 in reply to 394826
Ben Jammin:
Mike:
shouldn't it be
...
else if !patient.sick? || patient.dead?
...

Plus, if you're not sick, hopefully being buried isn't the solution. Obviously, patient.sick? needs to be a tri-state boolean of true, false, and LIFE_NOT_FOUND.


HAHAHAAHAHHAA

Re: But...Anything Can Happen!

2012-11-14 11:13 • by Paul Neumann (unregistered)
394855 in reply to 394852
iusto:
foo:
Reminds me of another "experienced" developer, who'd always use the mouse to select items and then do copy&paste through the context menu. Another one of those valued developers with over a decade of experience ...
Now you're exaggerating a little. If you had said, a guy scrolls up 2 pages of text to copy a short word so that he can paste it where he was below (to avoid typing it), then I'd understand. I noticed a couple of devs doing that for as little as 4-characters. Not to mention that IDE at the time was Visual Studio, where intellisense is present.
Real developers have no mouse. Real developers have no keyboard. Real developers whistle at 900 baud to a modem attached to ttyS0!
« PrevPage 1 | Page 2 | Page 3Next »

Add Comment