• (cs) in reply to long johnson

    Optimizing your code, with a few bug fixes:

    // No matter what, bury the patient first... if ((patient.sick || !patient.sick) && (patient.dead || !patient.dead)) buryPatient(); } else if ((!patient.sick && patient.sick) || (!patient.dead && patient.dead)) { // If we get here, the patient is God, lets heal him! healPatient(); }

    // It's ZOMBIE time! doCreateZombieFromPatient();

  • (cs) in reply to William F
    William F:
    CAPTCHA: ague - what I get from some of these stories

    How do you pronounce "ague"? "A jew" or "ag you" or "a goo" or "a gua" or ? Different pictures pop into my head depending on how it's pronounced :P

  • Stabbitha (unregistered)

    Where's the damn ponies?

  • Todd Lewis (unregistered)

    What I don't understand is, how can anybody who knows enough about programming to even make this mistake correctly not understand the problem with this type of logic? In all seriousness, WTF was he thinking, and why was he continuing to think it?

  • (cs)

    blah

  • (cs) in reply to Mythran
    Mythran:
    William F:
    CAPTCHA: ague - what I get from some of these stories

    How do you pronounce "ague"? "A jew" or "ag you" or "a goo" or "a gua" or ? Different pictures pop into my head depending on how it's pronounced :P

    404 Error: Correct Pronunciation Not Found.

  • Abico (unregistered) in reply to TRWTFVB

    Here's how people like Doug happen:

    An engineer teaches himself to program, probably in VB. He cobbles together a project that becomes very valuable to his organization. He works in a bubble; others may glimpse the code once in a while, but they're too busy with their own work to improve on the code. They may make recommendations, but Doug scoffs at the elitist attitude of "professional" programmers.

    "Why size arrays correctly when modern machines have practically infinite memory? Just make it as big as possible!"

    "Source versioning? Every change I make improves the code, so why keep the old versions? Besides, I know what changes I've made."

    "I'm getting nanosecond response time. See, these floats tell me so."

    "VB6 isn't multithreaded? Ha! It is in my code."

    Anyway, years of honing one piece of code and inertia imbue Doug with a false sense of understanding and confidence. He really thinks he knows what he's doing; in fact he thinks he knows better than everyone else. Hence, Doug.

    Yes, I could submit a week's worth of TDWTFs about the Doug I knew.

  • dkallen (unregistered) in reply to Abico
    Abico:
    <snip>

    Yes, I could submit a week's worth of TDWTFs about the Doug I knew.

    It's not the Doug you know that gets you. It's the Doug you don't know.

  • (cs) in reply to chris
    chris:
    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.

    Yep, NULL doesn't equal anything - NULL is supposed to mean "unknown," rather than being a specific concrete value of "nothing." Unfortunately, this distinction is lost on most people (mostly because in most languages NULL means "nothing")

    You can't know if two unknown things are the same as each other, thus NULL != NULL. To check for NULL you use the 'IS NULL' test instead.

  • long johnson (unregistered) in reply to Ben Jammin

    that was the point indeed :)

  • If (Doug) Else If (!Doug) (unregistered) in reply to dkallen
    dkallen:
    Abico:
    <snip>

    Yes, I could submit a week's worth of TDWTFs about the Doug I knew.

    It's not the Doug you know that gets you. It's the Doug you don't know.

    Else If (It's you the Doug && you don't know.)

    captcha: causa

  • Darth Paul (unregistered) in reply to Anoldhacker
    Anoldhacker:
    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.

    More obviously, defining a fact (or piece of logic) in more than one location ensures things will go wrong down the track.

  • Michael (unregistered)
    Luckily for Matt and the customers, management stepped in to end the stalemate. Doug is now the newest ex-developer...
    Now I know this is a fake story. Anyplace I've ever worked they would've fired Matt for being so "unreasonable".
  • Jack 27 (unregistered) in reply to Anoldhacker
    Anoldhacker:
    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.

    Doug wasn't smart enough to complement the whole condition:

    else if (!(a < 10 && b >= 30 && c != null))

    He tried to complement each inequality instead, and screwed it up even before anyone came by and modified it.

  • n_slash_a (unregistered) in reply to operagost
    operagost:
    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.
    As someone who works in the aviation industry, we do have coding standards that specify that all control paths must be covered. Thus, we have many constructs:

    if (a) do_something(); else if (b) do_something_else(); else assert(false); // should never get here

    The asserts do get compiled out in a release build, but are very good at finding things exactly like uninitialized variables.

  • n_slash_a (unregistered) in reply to Abico
    Abico:
    Here's how people like Doug happen:

    An engineer teaches himself to program, probably in VB. He cobbles together a project that becomes very valuable to his organization. He works in a bubble; others may glimpse the code once in a while, but they're too busy with their own work to improve on the code. They may make recommendations, but Doug scoffs at the elitist attitude of "professional" programmers.

    "Why size arrays correctly when modern machines have practically infinite memory? Just make it as big as possible!"

    "Source versioning? Every change I make improves the code, so why keep the old versions? Besides, I know what changes I've made."

    "I'm getting nanosecond response time. See, these floats tell me so."

    "VB6 isn't multithreaded? Ha! It is in my code."

    Anyway, years of honing one piece of code and inertia imbue Doug with a false sense of understanding and confidence. He really thinks he knows what he's doing; in fact he thinks he knows better than everyone else. Hence, Doug.

    Yes, I could submit a week's worth of TDWTFs about the Doug I knew.

    +1

  • foo (unregistered) in reply to Abico
    Abico:
    Yes, I could submit a week's worth of TDWTFs about the Doug I knew.
    Please do. :)
  • (cs) in reply to chris
    chris:
    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.

    If a given SQL engine correctly and fully implements NULL, then all normal predicates (= <> > <) return false if either or both test values are NULL. To test for NULL, you have to use "x IS NULL" or "ISNULL(x)" depending on the engine.

    If "a" is NULL in Rob's example then neither "if" would be true.

  • (cs) in reply to LoremIpsumDolorSitAmet
    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.

    int main() {
      int x,y;
      x = 10;
      if (x>10) y = 1;
      else if (x<10) y = 2;
      printf("%d", y);
    } 
    
  • Herp (unregistered) in reply to LoremIpsumDolorSitAmet

    Forgive me if this has already been mentioned, but if the intention is to have an else if contain an inverse condition to the if (that is, catch anything that the if does not catch), and the else if does not execute due to a logical error, then an important branch of code may be unexpectedly missed (by the developer) due to someone's stubborn refusal to use an else.

  • urbalt (unregistered) in reply to Abico
    Abico:
    Here's how people like Doug happen:

    An engineer teaches himself to program, probably in VB. He cobbles together a project that becomes very valuable to his organization. He works in a bubble; others may glimpse the code once in a while, but they're too busy with their own work to improve on the code. They may make recommendations, but Doug scoffs at the elitist attitude of "professional" programmers.

    "Why size arrays correctly when modern machines have practically infinite memory? Just make it as big as possible!"

    "Source versioning? Every change I make improves the code, so why keep the old versions? Besides, I know what changes I've made."

    "I'm getting nanosecond response time. See, these floats tell me so."

    "VB6 isn't multithreaded? Ha! It is in my code."

    Anyway, years of honing one piece of code and inertia imbue Doug with a false sense of understanding and confidence. He really thinks he knows what he's doing; in fact he thinks he knows better than everyone else. Hence, Doug.

    Yes, I could submit a week's worth of TDWTFs about the Doug I knew.

    A wise person once described this idea to me as: "some people with twenty years of experience really have twenty years of experience; some people with twenty years of experience just have one year of experience, twenty times."

  • (cs) in reply to Herwig
    Herwig:
    if (a)
    {
      doSomething();
    }
    else if (!a)
    {
      doSomethingElse();
    }
    else
    {
      file_not_found();
    }
    

    FTFY

  • Jack (unregistered) in reply to Darth Paul
    Darth Paul:
    defining a fact (or piece of logic) in more than one location ensures things will go wrong down the track.
    Right. That's why you need an "if statement wrapper":
    Function IFF (condition) {
      if (condition) {
        return true;
      } else if (!condition) {
        return false;
      } else if (true) {
        throw new universeException;
      } else if (!true) {
        throw new compilerBugFoundException;
      } else {
        assert ("Should'nt happen");
      }
    }
  • Abico (unregistered) in reply to urbalt
    urbalt:
    Abico:
    Here's how people like Doug happen:

    An engineer teaches himself to program, probably in VB. He cobbles together a project that becomes very valuable to his organization. He works in a bubble; others may glimpse the code once in a while, but they're too busy with their own work to improve on the code. They may make recommendations, but Doug scoffs at the elitist attitude of "professional" programmers.

    "Why size arrays correctly when modern machines have practically infinite memory? Just make it as big as possible!"

    "Source versioning? Every change I make improves the code, so why keep the old versions? Besides, I know what changes I've made."

    "I'm getting nanosecond response time. See, these floats tell me so."

    "VB6 isn't multithreaded? Ha! It is in my code."

    Anyway, years of honing one piece of code and inertia imbue Doug with a false sense of understanding and confidence. He really thinks he knows what he's doing; in fact he thinks he knows better than everyone else. Hence, Doug.

    Yes, I could submit a week's worth of TDWTFs about the Doug I knew.

    A wise person once described this idea to me as: "some people with twenty years of experience really have twenty years of experience; some people with twenty years of experience just have one year of experience, twenty times."

    I love it.

  • tation (unregistered) in reply to Todd Lewis
    Todd Lewis:
    What I don't understand is, how can anybody who knows enough about programming to even make this mistake correctly not understand the problem with this type of logic? In all seriousness, WTF was he thinking, and why was he continuing to think it?

    Simply put: he's a dumbass - who managed somehow to bullshit his way around jobs enough years to think of himself as someone with experience - but, in reality, he's a dumbass (and he's not the only one; no pun intended).

  • tation (unregistered) in reply to n_slash_a
    n_slash_a:
    operagost:
    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.
    As someone who works in the aviation industry, we do have coding standards that specify that all control paths must be covered. Thus, we have many constructs:

    if (a) do_something(); else if (b) do_something_else(); else assert(false); // should never get here

    The asserts do get compiled out in a release build, but are very good at finding things exactly like uninitialized variables.

    That logic is dumb, as is who imposed it on you, as are you who accepts it. Reading that tears my head. If my employer made my type that, I would quit. I my employee typed that, I would fire them. I don't care if you're coding a blog or software to control jets - it's dumb, and it doesn't make sense.

  • Nagesh (unregistered) in reply to Paul Neumann
    Paul Neumann:
    Real developers have no mouse. Real developers have no keyboard. Real developers whistle at 900 baud to a modem attached to ttyS0!
    Flood of obligatory xkcd links to follow in 3 ... 2 ... 1 ...
  • Gunslinger (unregistered)

    So, TRWTF is that the correct thing happened and it's still being shown on this website?

  • Gunslinger (unregistered) in reply to tation
    tation:
    n_slash_a:
    operagost:
    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.
    As someone who works in the aviation industry, we do have coding standards that specify that all control paths must be covered. Thus, we have many constructs:

    if (a) do_something(); else if (b) do_something_else(); else assert(false); // should never get here

    The asserts do get compiled out in a release build, but are very good at finding things exactly like uninitialized variables.

    That logic is dumb, as is who imposed it on you, as are you who accepts it. Reading that tears my head. If my employer made my type that, I would quit. I my employee typed that, I would fire them. I don't care if you're coding a blog or software to control jets - it's dumb, and it doesn't make sense.

    No, you're dumb, for not specifying what part doesn't make sense. There are several concepts in the post you quoted and several of them do make sense and are not dumb. For instance, the main concept is that all control paths must be covered, which is not a dumb thing to require. So, because we can assume that you're calling that dumb logic, we must assume that you are the dumb one. QED

  • Ben Jammin (unregistered) in reply to tation
    tation:
    n_slash_a:
    <snip> As someone who works in the aviation industry, we do have coding standards that specify that all control paths must be covered. Thus, we have many constructs:

    if (a) do_something(); else if (b) do_something_else(); else assert(false); // should never get here

    The asserts do get compiled out in a release build, but are very good at finding things exactly like uninitialized variables.

    That logic is dumb, as is who imposed it on you, as are you who accepts it. Reading that tears my head. If my employer made my type that, I would quit. I my employee typed that, I would fire them. I don't care if you're coding a blog or software to control jets - it's dumb, and it doesn't make sense.

    // test flying object (fo) type... if(fo.hasBeak) return "It's a bird!" else if (fo.hasWings) return "It's a plane!" else assert(false) // Superman ain't real!

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

    Yes, that's standard SQL. And yes, very poorly thought out... resulting in expressions like (x = y or (x is null and y is null)) scattered throughout the system... and as often than not, someone has the conditions wrong.

  • Simon (unregistered) in reply to tation
    tation:
    That logic is dumb, as is who imposed it on you, as are you who accepts it. Reading that tears my head. If my employer made my type that, I would quit. I my employee typed that, I would fire them. I don't care if you're coding a blog or software to control jets - it's dumb, and it doesn't make sense.

    It's not dumb - it's just paranoid. And sometimes, that kind of paranoia is a really good idea - if something should never happen, don't just assume that it never will.

  • JV (unregistered)

    TRWTF is that he got hired in the first place.

  • Buzz Lightning (unregistered)

    FRIST!!! I did it - FINALLY!

  • some pony (unregistered) in reply to n_slash_a
    n_slash_a:
    As someone who works in the aviation industry, we do have coding standards that specify that all control paths must be covered. Thus, we have many constructs:

    if (a) do_something(); else if (b) do_something_else(); else assert(false); // should never get here

    The asserts do get compiled out in a release build, but are very good at finding things exactly like uninitialized variables.

    For cases including 'c' 'd' 'e' and 'f', i would agree, but when one has just two statements, would it not be more prudent to do assert(b) in the else clause together with do_something_else(); rather then to create the third clause to assert false?

  • Jimbo (unregistered) in reply to LoremIpsumDolorSitAmet
    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.

    I don't think Alex has been making these up for some time now....he's got a group of brainstormers to [strikethrough]create[/strikethrough] collaborate the stories now!!

  • Gigaplex (unregistered) in reply to plaidfluff

    I disagree to some extent. NULL to me means "known to be invalid", not "unknown". Something logically can be valid but unknown given the context. If two things are known to be invalid they can logically be considered equivalent.

  • Mikhail (unregistered) in reply to Geoff
    Geoff:
    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.
    static int mushroomsPicked = 4;
    int getMushrooms()
    {
      return mushroomsPicked++;
    }
    

    main() { if(getMushrooms()<5) { printf("We need to pick more mushrooms\n"); } if(getMushrooms() == 5) {
    printf("We can stop now\n"); } else if(getMushrooms()>5) { printf("How the hell did we pick too many mushrooms?\n"); } }

  • Mikhail (unregistered) in reply to Mikhail
    Mikhail:
    Geoff:
    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.
    static int mushroomsPicked = 4;
    int getMushrooms()
    {
      return mushroomsPicked++;
    }
    

    main() { if(getMushrooms()<5) { printf("We need to pick more mushrooms\n"); } else if(getMushrooms() == 5) {
    printf("We can stop now\n"); } else if(getMushrooms()>5) { printf("How the hell did we pick too many mushrooms?\n"); } }

    FTFM
  • willie (unregistered) in reply to Nemo
    Nemo:
    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 SCHRODINGERS_CAT.

    FTFY

    FTFAOY

    All of

  • flutes (unregistered) in reply to plaidfluff
    plaidfluff:
    chris:
    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.

    Yep, NULL doesn't equal anything - NULL is supposed to mean "unknown," rather than being a specific concrete value of "nothing." Unfortunately, this distinction is lost on most people (mostly because in most languages NULL means "nothing")

    You can't know if two unknown things are the same as each other, thus NULL != NULL. To check for NULL you use the 'IS NULL' test instead.

    Does infinity = infinity?

    It's kind of the same concept. NULL is nothing - it's not specific (it's not really quantifiable - it's not even 0 - having none of something is not the same as having nothing (none of everythiong))). You can't compare two nothings and decide they're the same, bnecause they're, well nothing. Infinity is massviely big and not specific.

    I'm goin for a panadlol

  • (cs)

    if (++a == 0) { a = a + 1; } else if (++a != 0) { a = a + 2; }

  • (cs) in reply to Jimbo
    Jimbo:
    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.

    I don't think Alex has been making these up for some time now....he's got a group of brainstormers to [strikethrough]create[/strikethrough] collaborate the stories now!!
    The extra code paths come from the extra logic required to test for the !(condition), assuming that the "!(condition)" is actually coded correctly. Doug just doesn't understand how programming languages work; the "else" branch will always be taken if the "if" branch fails. The only time that "anything can happen" is if the processor is broken.

    I'll just go back under my bridge now.

  • (cs) in reply to Gigaplex
    Gigaplex:
    I disagree to some extent. NULL to me means "known to be invalid", not "unknown".
    Then you need to re-read Codd's 12 Rules. In a RDBMS, null markers indicate missing or inapplicable data. Example of missing data: Birthdate of someone whose birth records were lost. They do have a birthday but they don't know which day of the year it was. Example of inapplicable: Weight of a mp3 file. Hair colour of a bald man. Thought experiment: Stick your right hand into a bowl of lollies, grab a handful, and then remove your closed fist from the bowl. How many lollies are in your right hand? Unknown. There is an actual value - you just don't know it at this point in time (without opening your fist and couting the lollies). Now put three lollies in your left hand. Is the number of lollies in your left hand equal to the number of lollies in your right hand? Well, since the number of lollies in your right hand is unknown then you can't know if they are equal or not. KnownValue = NULL --> NULL. Next thought experiment: Stick both hands into the bowl and grab a handful of lollies. Is the number of lollies in your left hand equal to the number of lollies in your right hand? Since you don't know the number of lollies in either hand then you can't know if they are equal or not. NULL = NULL --> NULL. Hint: Use the phrase "null marker" rather than "null value". It will help reduce misunderstandings. For "missing", use words like "maybe", "perhaps", "possibly", "dunno". P.S. null markers in a RDBMS have nothing to do with null pointers in programming languages.
  • (cs) in reply to Simon
    Simon:
    It's not dumb - it's just paranoid. And sometimes, that kind of paranoia is a really good idea - if something should never happen, don't just assume that it never will.
    What's dumb is feeding the trolls. Knock it off.
  • Eric Jablow (unregistered)

    And then there's:

    private volatile boolean b;
    
    //Method that updates b.
    
    //Other method that updates b
    
    public void failsRandomly() {
      if (b) {
        bWasTrue();
      else if (!b) {
        bWasFalse();
      } else {
        bWasFileNotFound();
      }
    }
    
  • Norman Diamond (unregistered) in reply to n_slash_a
    Michael P:
    Some coding standards (like, say, the ones used for C++ on the US Joint Strike Fighter program)
    But not the ones used for civil aviation? No wonder knowledgeable people were afraid to fly even before the TSA made it worse.
    Michael P:
    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.
    operagost:
    Just in case of FILE_NOT_FOUND in your boolean.
    Only if the preceding code was "if (something) doit else if (!something) dontit" instead of a plain "if (something) doit else dontit". If it was a nullable boolean then the former version needs "else circularfileit".
    n_slash_a:
    As someone who works in the aviation industry, we do have coding standards that specify that all control paths must be covered. Thus, we have many constructs:

    if (a) do_something(); else if (b) do_something_else(); else assert(false); // should never get here

    The asserts do get compiled out in a release build, but are very good at finding things exactly like uninitialized variables.

    TRWTF. By compiling out the error checking, you arrange for errors to result in crashes instead of bug reports. Just like giving black boxes to test pilots but omitting black boxes from planes in actual use by the public.

    I'd rather see the plane tell the pilot "Keep your eyes open and talk to traffic control now because I'm going to spend the next 5 minutes rebooting" instead of "resume next and crash".

  • Norman Diamond (unregistered) in reply to Mike
    Mike:
    shouldn't it be ... else if !patient.sick? || patient.dead? ...
    If a plane crashes on the border between the United States and Canada, where will the survivors be buried?
  • Norman Diamond (unregistered) in reply to foo
    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 ...
    Oh neat, a story about a developer who adds bugs by doing unnecessary editing reminds you of another developer who sometimes avoided adding bugs by double checking the editing they were about to do?

    If the programmer remembers they want to use the same variable that was used two screenfuls of code earlier, but doesn't remember what it was called, which letter should they type in order to get Intellisense to give them a list of reasonable candidates?

    Well anyway, you'd make a good manager, with typical inability to distinguish which of your subordinates are competent and which aren't. You'd discover pretty quickly which ones have no social skills, but you won't understand why, and you'll fire them immediately.

  • (cs) in reply to Abico
    Abico:
    Here's how people like Doug happen: {VB6} {years of honing one piece of code} {false sense of understanding and confidence} {thinks he knows better than everyone else} Yes, I could submit a week's worth of TDWTFs about the Doug I knew.
    Let me guess, he wrote a file text searcher cum media player?

Leave a comment on “But...Anything Can Happen!”

Log In or post as a guest

Replying to comment #:

« Return to Article