• tekHedd (unregistered)

    I had something funny to say, but akismet says my comments are all spam. Forget it.

  • (cs) in reply to tekHedd
    tekHedd:
    I had something funny to say, but akismet says my comments are all spam. Forget it.
    Then the other RWTF is developers who can't get around Akismet.
  • (cs) in reply to hoodaticus
    hoodaticus:
    tekHedd:
    I had something funny to say, but akismet says my comments are all spam. Forget it.
    Then the other RWTF is developers who can't get around Asshat.

    Censored TFY.

    Be careful. Criticism of, or even mentioning Asshat, is known to invoke the wrath of Asshat. Allegedly.

  • Michael Cowan (unregistered)

    Where is the unit test?

  • (cs)

    I'm now tempted to find out if various compiled languages optimize those ifs away.

  • tekHedd (unregistered) in reply to hoodaticus
    hoodaticus:
    tekHedd:
    I had something funny to say, but akismet says my comments are all spam. Forget it.
    Then the other RWTF is developers who can't get around Akismet.
    Ad hominem much?

    Anyway, I did get around it. I deleted everything interesting from my comment, and Akismet let me right through. Success! (Hey, I still get to laugh at the joke, so it's a win as far as I'm concerned.) :>

  • (cs) in reply to tekHedd
    tekHedd:
    hoodaticus:
    tekHedd:
    I had something funny to say, but akismet says my comments are all spam. Forget it.
    Then the other RWTF is developers who can't get around Akismet.
    Ad hominem much?

    Anyway, I did get around it. I deleted everything interesting from my comment, and Akismet let me right through. Success! (Hey, I still get to laugh at the joke, so it's a win as far as I'm concerned.) :>

    And you're the joke to me, so I win too!

  • noland (unregistered) in reply to empathic
    empathic:
    airdrik:
    Freek:
    To everyone that thinks the test on the status is redundant, think again. A request for a non-existing page will result in a readyState 4, while the response status will be 404 (not found). Or, to make it simple, the readyState is reflects the state of the request, while the status reflects the state of the response. Google for Http readystate and open the second result if you want to learn more.
    You missed the fact that they use the switch to check the readyState and then used an if to check the readyState again.

    Of course if readyState changes between the switch and the if then it will miss the break statement and flow into the next case statement. At least with this setup, it won't flow into the wrong if block if it changes midway through.

    Of course this function gets called each time readyState changes, so assuming the possibility of readyState changing during the execution of this function causing it to flow between switch cases, you would end up with multiple executions running the content of certain cases multiple times - two (or more) alerts and two (or more) dataInsert calls if readyState changes fast enough. And how do we prevent that? More code, obviously! Like adding some kind of framework that ensures that the code only gets executed once by a single request.

    Or use a local variable to store the numeric code?

    Whoa. This site is full of european retards, hail USA, hail. God save the USA, may the green cards go out of stock soon.

    To save the reputation of european coders:

    1. No, "break" only breaks out of the nearest loop or case-stetement (or, if labled, the labled loop) - No way break can ever break out of any compund-statement (block)

    2. No, the readyState can't change while the code is executed. JavaScript is single-threaded, all events and their callbacks are atomic. (Therefor the inner "if" is just scattering while speaking JS.)

    3. Yes, it's quite reasonable to check the status and readState==4 is the right place to do it.

    4. It's totally ok to use hardcoded numeric values in JS, since a) JS allows only for hard-coded case-labels (and the value checked is numeric). b) The values are part of the underlying protocol. They are not expected to change. (This would not be true while dealing with protocols not frozen yet like web-sockets. But XMLHttpRequest is a frozen standard.)

    OMG!

  • Eric (unregistered) in reply to Jason Hooper

    Agreed. I was about to post nearly the same thing. There is nothing wrong with this code other than slightly inefficient and it is likely that the coder intends (or intended) to do more with it down the road.

  • byron (unregistered)

    unless of course he just threw in the breaks as a place holder until we could write in some code to handle the other states.

  • Putr (unregistered)

    First i was like "O so he checked for statuses he didnt care about.. ok whatever" .. but than i saw it and i shited bricks!

  • (cs)

    This code is reminiscent of a lot of awful VBA code I have witnessed over the years. Lack of the use of CONSTANTS and the lack of the application of ENUMERATIONS just smacks of a lazy or incompetent programmer. I guess both is also possible.

    4 is just a number. In the context of this code, what does it mean ? That's the question.

  • ArrowHead (unregistered)

    It's computing using quantum physics. The state of something might change just by being observed

  • Mike (unregistered) in reply to Eric
    Eric:
    There is nothing wrong with this code other than slightly inefficient and it is likely that the coder intends (or intended) to do more with it down the road.
    I really don't think "I might need an if-statement later on" is a valid reason for adding useless if's. Unless you're working in some very strange place where you're only allowed to add a certain number of characters to your code per day, there is no reason to "prepare for the future" in this manner. (And if you are, then that would be the real WTF.)

    If at some point you need to do some conditional processing inside one of the case statements, then add an if at that point. The ease of updating code is kind of the entire point of having high-level languages which are easy for humans to write.

    This seems like the opposite of "premature optimisation" - premature expansion perhaps? If there is no reason for the code to be there, then it shouldn't be there. The only way that I'd think it was a good idea would be to have the empty case statements there with a comment along the lines of /* TODO: update widget when this state occurs */ or similar.

  • Bob Surunkle (unregistered)

    'dats the most explicitish thing I eva hoid.

  • Timothy (TRiG) (unregistered) in reply to RootKid

    Ah, so now we have racism and ableism.

    Would any more bigots like to show themselves?

    TRiG.

  • Timothy (TRiG) (unregistered) in reply to RootKid
    RootKid:
    trwtf:
    Indian coders are always first but you have to ask yourself - do you want it done fast or do you want it done right???
    [image]

    Ah, so now we have racism and ableism.

    Would any more bigots like to show themselves?

    TRiG.

  • Stunned at this Sick Fuck (unregistered) in reply to Timothy (TRiG)
    Timothy (TRiG):
    RootKid:
    trwtf:
    Indian coders are always first but you have to ask yourself - do you want it done fast or do you want it done right???
    [image]

    Ah, so now we have racism and ableism.

    Would any more bigots like to show themselves?

    TRiG.

    Did you just compare a team of Indian coders to a fucking retard? Is that seriously what you think, that Indians are in the same boat as fucking Down syndrome kids? What kind of sick fucking racist weirdo are you? Fucking die in a fire you prick.

  • Douglastab (unregistered)

    Achat mГ©dicament en ligne fiable https://kamagraenligne.com/# pharmacie en ligne france fiable

Leave a comment on “Sturdy Switch”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article