• rjs (unregistered) in reply to Sigh

    lol ok moron.. you are not half as smart as you think you are.

  • (cs) in reply to wtf
    wtf:
    Fred:
    Refactoring best case: the code still does exactly what it did before, but it's now possible to improve and extend it without breaking stuff.

    Refactoring worst case: you introduce new bugs because you took it upon yourself to change something that is invisible to everybody who pays your salary, and your unit tests pass but three months later you find that another piece of the application which relies on the undocumented side effects of the original has been producing incorrect results, by which time it is too late to revert to the previous kludgy hacked-together junk and try again another time, and it takes a dozen people a week to conduct an audit and analysis and make corrections.

    And then you get fired, and on your way out of the building you get bitten by a rabid dog, and in shock and pain you stumble into traffic and get knocked down by a truck. And then a giant meteor hits the earth, destroying all life.

    FTFY.
    FTFY.
  • (cs) in reply to Paul
    Paul:
    Jemmy:
    C is pretty good at chasing away idiots who'd go on to become incompetent coders :)
    OK we've tried making computers easier for a couple decades now and look where it got us. It is time to go back to a sort of built-in competence test that winnows out the idiots before they get a chance to launch yet another cesspool.

    Bert Glanstrom was such a programmer but they wouldn't employ him because he hadn't played with all the latest gadgets, took a donut which was there in a box in his interview room but wasn't intended for him, and had a name someone had decided to blacklist.

    No jobs for intellects, just for idiots with nice personalities who have played with all the right toys.

  • Not Not Not Nand (unregistered) in reply to Yo-Yo Mo
    Yo-Yo Mo:
    Gozer Gozerian:
    bertram:
    Morrell:
    tri-state boolean... now that's nuts :)

    You must be new here ;)

    That's right Morrell, a tri-state boolean is actually considered minimum among professionals. Also a four and five-state booleans are sometimes used. Only six and above ones can be a bit nuts. ;)

    For future ease of reference, shouldn't the nomenclature be standardized?

    Three-state boolean = troolean Four-state = foolean Five-state = quoolean [pronounced cool-lee-ann]

    States greater than five could be grouped either as droolean or eff-yoolean.

    All of them should be called TDWTFooleans. It's a modification of Hungarian Notation that self-documents the variable name.

  • (cs) in reply to by
    by:
    golddog:
    Now just imagine the fun E.H. has with such quandaries line-after-line and day-after-day.
    Does E.H. refactor this code when he comes across it, or leave it and bitch?

    That's acutally one of the things I find fun about my job; taking some crap code and refactoring it into something good. makes me feel I've made our little world slightly better.

    Who are you, Hitler?

    Made me laugh ( yes of course fucking Out Loud, all laughter is by definition and how many people who type ROFLMAO are even fucking laughing, let alone rolling on the floor - I wish their arses would really fall off, now that would be funny)

  • Ichneumon (unregistered) in reply to Mike D.
    Fred:
    Refactoring best case: the code still does exactly what it did before, but it's now possible to improve and extend it without breaking stuff.
    That's the second best case.

    Refactoring BEST case: While deciphering WTF the WTF code does, you determine that the reason it's so convoluted is because the original idiot author couldn't wrap his brain around the real problem and made a mess of it, and that as a result the WTF code doesn't actually function properly (at least in certain cases, perhaps not at all), so instead of replacing the code with code that "still does exactly what it did before", you fix the code in the process of making it more obvious/readable/maintainable. Do this a few times and you'll be the local hero, someone with a reputation for spotting/fixing longstanding (or not yet manifested but potentially OMG) quirks and bugs in the application.

    Ok, so that's not technically "refactoring" if you fix it, but let's face it, how many times have you started out merely simplifying some convoluted piece of code, or just working carefully through it to figure out what the heck it does, and in the process discovered how broken it was? Once you're at that point, you might as well rewrite it to be both straightforward AND correct, and you wouldn't have gotten there if you hadn't started out to "just" refactor some P.O.S chunk of code.

    In the case where the overly complicated WTF code turns out to actually work right (and that's not the way to bet), you've already invested the time and effort to know how to properly recode it cleanly, so you'll be doing the next programmer a favor by taking a moment to do that recoding, so that a) he won't have to go through the same painful process you did when you had to stop and decipher/verify the WTF code, and b) he won't be as likely to "guess" wrong about what it does (if he's not as tnorough as you are) and bolix something up while he's maintaining/upgrading it.

  • Thenonymous (unregistered) in reply to Scarlet Manuka

    [quote user="Scarlet Manuka"][quote user="wtf"][quote user="Fred"]Refactoring best case: ... a giant meteor hits the earth, destroying all life.[/b] [/quote] FTFY.[/quote] FTFY.[/quote] FTFY.[/quote]

  • (cs) in reply to Ah yes
    Ah yes:
    The best part about the code is it will be easy to add the conditionals for less than and greater than as well.

    you mean less than True or more than false?

  • (cs) in reply to DonaldK
    DonaldK:
    Matt:
    I can't not misunderstand what he was not trying to unachieve.

    Let's break it down:

    can't not = CAN ... I CAN misunderstand what he was not trying to unachieve.

    CAN misunderstand = misunderstand = do not understand ... I do not understand what he was not trying to unachieve.

    not trying to unachieve = trying to achieve ... I do not understand what he was trying to achieve.

    Ditto.

    Hehe, reverse engeneering

Leave a comment on “Boolean Illogic”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article