• ray10k (unregistered)

    Always !!fun!! to see systems crash and burn under what should be simple changes.

  • bvs23bkv33 (unregistered)

    new type unit_testing has three states: true, false and still_no

  • Flag1 (unregistered)

    Painful to read. We can't all be super-programmers with a perfect understanding of the dependencies of each statement in our mind, but no testing when such amounts are involved is truly worse than failure.

  • W (unregistered)

    The WTF here is that Mr A assumed the variable was a boolean.

  • (nodebb) in reply to W

    The WTF here is that Mr A assumed the variable was a boolean

    TRWTF is using NodeJS - JavaScript dynamic typing so even typos compile.

    No source control, testing or release management.. they deserve what they go

  • RLB (unregistered)

    Isn't it obvious? It's a quantum boolean: resolved true, resolved false, and not yet observed by a macroscopic function.

  • Brian (unregistered)

    The problem here isn't the lack of unit tests (that's one of many problems with this example, but not he biggest one), it's Mr. A's lack of due diligence prior to making this change. If he had done a simple code search on that variable, he probably would have found pretty quickly that a null value is meaningful.

    I learned a long time ago that you can't just go changing things without putting in a reasonable amount of effort toward understanding the consequences of the change.

  • TheDaveG (unregistered) in reply to Brian

    +1. Worse than not having unit tests, it looks like Mr. A. didn't even test his change.

  • JG (unregistered) in reply to TheDaveG

    When you end up in a company like this one then testing properly testing your chang is seen as not being productive and you end up being fired as being too slow or not a team player.

  • User (unregistered) in reply to TheDaveG
    TheDaveG:
    +1. Worse than not having unit tests, it looks like Mr. A. didn't even test his change.

    The thing is: Mr. A probably assumed the change won't actually alter the application logic. How would one test a change that is not supposed to have an externally observable effect?

  • User (unregistered) in reply to JG

    2018-04-25 Reply

    When you end up in a company like this one then testing properly testing your chang is seen as not being productive and you end up being fired as being too slow

    Is being fired from a company like this one a bad thing?

  • That Guy (unregistered)

    Thanks to reddit i have become aware of the MsoTriState enumeration.

    https://msdn.microsoft.com/en-us/library/aa432714%28v=office.12%29.aspx

    It has (you guessed it) five states.

    Two of these states are supported are supported.

    Confusingly the supported states are msoFalse and msoTrue. And msoFalse is even 0. !?!?

    Luckily msoTrue is -1 otherwise it could have been confused with other truth values of other languages, which are by convention 1.

    The developer who tried to introduce msoCTrue has been sacked. (And msoCTrue is now unsupported.)

  • P (unregistered) in reply to TheDaveG

    It's easy enough to make an assumption though, such as the fact that you and Brian assumed that Mr A made this change. It doesn't say that in the article...

  • WTFGuy (unregistered)

    We can't even get past two WTF entries in a row before we re-enter the world of non-binary booleans.

    It sure seems like it's past time for anyone and everyone to abandon the naive thought that actual booleans in actual languages are two-stated.

  • Raj (unregistered) in reply to Howard Richards

    TRWTF is blaming the tool. Countless people use NodeJS properly, there is nothing wrong with it. For some workloads it outperforms other technologies, and the ratio of LOC to app feature is quite low. It does have its peculiarities and can lead to a fragile stack of dependencies if done wrong, but the same can be said of pretty much any language.

  • Comics Reader sans Sans (unregistered)

    Interesting take on Mr A, the truth seeker hero created by Steve Ditko (the creator of Spider-Man). For those who don't know that little gem from the 70s, Mr. A's outlook on morality is that there are no gray areas, only black and white -- booleans, got it?

    Snoofle, you're showing your age. Oh, wait, so am I.

  • (nodebb) in reply to Brian

    ...simple code search on that variable...

    In JavaScript? In node.js? What a clever joke...best one I've heard all year.

  • (nodebb)

    This is just not correct. An uninitialized JS variable (NodeJS is just normal JS) has value of undefined, which evaluates false. Setting it to false is a boolean primitive, which also evaluates false. You can make a Boolean wrapper of Boolean(false) which evaluates true, but that's not what's being shown there. There is no such thing as NULL, only null, which also evaluates false.

    So the WTF is that this example is clearly fraudulent, by someone who doesn't know JS.

  • (nodebb)

    Had the original developer written:

    parcel.consolidated = null;

    The entire issue would likely have been avoided.... Remember Write Code for the Readers of the Code FIRST, and for the execution of the code second

  • kirby (unregistered) in reply to TheCPUWizard

    But littering your code with stuff like this makes it more likely that your colleagues will introduce multi-million dollar bugs and will be passed over for promotion, while you're less likely to fall for your own traps. That's just healthy competition. Why do you hate freedom?

  • CowgirlNelly (unregistered)

    "especially true" and "even more true"? It appears that linguistically, you are employing multi-state booleans, too.

  • QA Dude (unregistered)

    NOTABUG WONTFIX revenue enhancement feature

  • I am a robot (unregistered) in reply to Brian

    THIS!

  • TechnicallyCorrect (unregistered) in reply to kamimark

    This is just not correct. An uninitialized JS variable (NodeJS is just normal JS) has value of undefined, which evaluates false.

    While this is technically correct, this is not a variable, but a field. And fields can be set or unset (if unset, attempting to access the field returns undefined). If the code was:

    if ('consolidated' in currentParcel) {
  maybeApplyDiscount(currentParcel);
} else {
  currentParcel.consolidated = determineIfDiscountApplies(currentParcel);
  maybeApplyDiscount(currentParcel);
}

    then the described behavior would happen and (for bonus points) setting parcel.consolidated to null would also break everything.

  • Kashim (unregistered) in reply to RLB

    So instead of True, False, FILE_NOT_FOUND, it was much more quantum; True, False, NOT_OBSERVED_YET.

    Also, I hope someone learned their lesson: In a language that assigns a default value of NULL, there is no such thing as an uninitialized variable, and you should check for that. This is really just a WTF about making sure that you learn the different ways that variables can be initialized, and don't assume that the last guy did anything unintentionally unless you know it to be true.

    "Hey, that looks like it could be a bug. I'm going to preemptively fix it." is a bad way to do your job.

    "Hey, that looks like it could be a bug. I'm going to research it to make sure that it really is, and then fix it if it really is." is how we make the world a better place, and not a worse one.

  • I Am A Robot (unregistered)

    So it's the standard of something was found and the person decides to leave the company. Are jobs really that easy to find and do employers not look suspiciously at someone who was in a position for a couple of months and left?

  • snoofle (unregistered) in reply to I Am A Robot

    Jobs are easy to find. Good jobs are much fewer and further between.

    FWIW, I've walked away from a couple of jobs after a VERY short time (once after 4 weeks) because the situation was SO wtf that I just didn't want to go down the drain with the company. I got the same reaction (from prospective employers) after leaving those short term jobs as after leaving much longer term jobs; the length of employment didn't seem to register so much as the fact that I had left the job at all. I have absolutely no clue why.

  • (nodebb)

    The Truth? You can't handle the truth!

    Alas, it seems that this is a common thread in these discussions. I yearn for the days when there was one "truth" and the rest were false. I digress, but sometimes Fortran got it right.

  • Gretchen (unregistered) in reply to snoofle

    I'd agree. Jobs are easy to find. Good jobs are easy to find but take a lot longer. I've walked away from a few places as they were so toxic.

    Interestingly, I've seen the exact same error at a company I worked at. I suspect it's the same place so I know exactly who submitted this.

    It was an act of supreme stupidity that still did not make senior managers wake up.

    Mr A did not stuck around long sadly. At least he jolted the better Devs out of their torpor and inspired them to move on as well. Including me.

    Happy days...

  • ZZartin (unregistered)

    So just another case of a bad developer not understanding the system he was working in and making a change to something that wasn't a bug.

  • Axel (unregistered)

    Know your memes. It's not "FILE_NOT_FOUND," it's "FileNotFound."

    At least, that's how it was in the original submission. But I guess memes can warp and degrade over time. Like my body!

  • RLB (unregistered) in reply to JG

    Never properly test your Chang, just dump it down the drain. It's a completely unimpressive pilsner and the Thai should be ashamed of it.

  • ratboy (unregistered) in reply to kamimark

    Let's test that:

    $ node

    var x undefined x == undefined true x == null true x == true false x == false false

    This in node.js

  • I'm not a robot (unregistered) in reply to TheCPUWizard

    I'm pretty sure that was what the original developer intended to write, they just forgot the "= null" due to some sort of braino. If they were solely concerned with maximum possible efficiency, as you seem to be insinuating, there'd be no point in writing a bare property reference like that in the first place.

  • tharg (unregistered)

    Isn't writing applications in javascript somewhat like writing mission-critical database application in VB script? Using edlin? If a variable could be any type and hold any value (or not, or cause a crash when referenced), then it WILL. When I explain an edge case and have a customer say "well, how often is THAT going to happen?" my usual response is "about thirty minutes after putting the system in production"

  • Berk (unregistered) in reply to User

    By confirming that is has no effect!

  • Dyspeptic Curmudgeon (unregistered) in reply to RLB

    "It's a quantum boolean: resolved true, resolved false, and not yet observed by a macroscopic function."

    It's a Schroedinger boolean. And we are not sure that there even IS a cat. Much less a box.

  • isthisunique (unregistered)

    There are very good reasons why people don't use unit tests but first and most of all is that they don't guarantee correctness.

    On top of that no one really uses commonsense or appropriate strategies when using them so that they pay for themselves. It's very easy to just create waste when creating unit tests. You're doubling the amount of code. You're also often doubling the maintenance work.

    This is especially the case when doing unit tests "properly" which means not using them for integration and requiring them thoroughly for everything. Even used thoroughly they text a very specific thing, you still need your other types of tests. I've seen situation where codebases are bloated with several times the amount of code needed. Then you come along and delete ll of that code replacing it with something smaller. Out go the units tests with it and you wonder what's the point.

    Some people have some strange religious notions of unit tests such as that unit tests will ensure good code when in reality it's neither here nor there. They might help a bit but ultimately bad code means bad unit tests.

    Despite the label claiming that they magically make refactoring easy, nothing could be further from the truth in most cases. If your code is good out the box and wont be likely to need significant rework or restructuring in the future then you might cut out some of the waste.

    If people thought about testing more carefully like only investing in unit tests for critical functions (for example, I'm about to implement a delete function against a critical piece of infrastructure, I need to make sure nothing silly happens like it doesn't append the WHERE condition) and also using them for integration tests (just test main, massive code coverage) essentially targeting hotspots then it wouldn't be so bad.

  • Zenith (unregistered) in reply to isthisunique

    Unit tests lose their effectiveness as you go up the business logic chain. I have a core library that has a few hundred unit tests written against it. The more moving parts you introduce, the more complex your test setup has to be and the more likely the failure isn't where the test says it is.

    Also I resent the assertion that all changes break some other part of the system because it's the same defeatist view as all code being buggy. That's just not true unless you work with fools. Some people actually can write quality code and anything you think you gain from cowing them to make the D students feel better you lose in lost productivity or exodus to somewhere else that isn't bent on handcuffing independent thinkers.

  • anonymous (unregistered) in reply to W

    TRWTF is that the code wasn't commented. The previous developer could've easily written // this variable is left uninitialised and its final value is decided in PackageProcessor.js. Even better, explicitly initialise the variable to null and add a similar comment explaining why.

Leave a comment on “The Search for Truth”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article