• Your Name (unregistered)

    //and by comment your code I mean sarcastically comment your code

  • Anonymous Cow-Herd (unregistered)

    A single flag with a single return point, a home-brew search-and-replace ...

    It's like I'm really sat in front of a C64 in 1985.

  • Machtyn (unregistered) in reply to Anonymous Cow-Herd
    Anonymous Cow-Herd:
    A single flag with a single return point, a home-brew search-and-replace ...

    It's like I'm really sat in front of a C64 in 1985.

    or any high school programming class. (Oh, wait, that was Pascal and 1990 for me... not too far removed from 1985.)

  • BlueCollarAstronaut (unregistered)

    FRIST! // And my 'Frist', I mean fourth.

  • no u (unregistered)

    that's not a comment. THIS is a comment!

  • lame guy (unregistered) in reply to no u

    Your mom is a comment.

  • AssBlaster (unregistered)

    Multiple return points are bad for the same reasons GOTO's are mostly bad. Also, they tend to be used a lot by people who don't know what an exception is.

  • Duke (unregistered)

    If there's one redeeming quality in Java, it's that you can't do half of the things suggested in this wtf.

  • Ankheg (unregistered) in reply to BlueCollarAstronaut
    BlueCollarAstronaut:
    FRIST! // And my 'Frist', I mean fourth.
    Shouldn't that be 'frouth'?
  • Quote (unregistered) in reply to BlueCollarAstronaut 
    // some people aren't frist
if (checkFrist)
{
    lStr = str;
}
else
{
    //by not frist I mean frist
    lStr = str.ToFrist();
}
  • dguthurts (unregistered)

    // reinvent the wheel

    'nuff said.

  • (cs)

    The code is bad, but this bit really concerns me:

    /// Called by MatchWord
    I can only guess what MatchWord must look like. 
    private bool MatchWord(ref string str, bool checkCase, bool checkWholeWord, string strFind)
{
    return ChangeWord(str, checkCase, checkWholeWord, strFind, strFind);
}
  • Frank (unregistered) in reply to AssBlaster
    AssBlaster:
    Multiple return points are bad for the same reasons GOTO's are mostly bad. Also, they tend to be used a lot by people who don't know what an exception is.
    And what if you're programming in a language which doesn't have built-in exception handling, like C? I've seen C code which was a horrific tangled mess because the project lead declared that every function must have only 1 return point. As a result, after every function call was an if-structure designed to make sure the calling function would only continue if the called function returned successfully. At the end of each function was a huge pile of closing brackets. God help you if mistakenly deleted an opening bracket a page earlier. The result was code which I found to be very un-maintainable. It really made me say "WTF?"

    Your point is well taken if you are implementing exceptions. But even in a language which supports exceptions natively, exception handling can result in much slower code. Thus, it is often not used in embedded code. In that case, I think multiple return points can actually result in much faster and more maintainable code.

  • (cs)

    At least it only has one return.

    Oh wait - I don't give a crap.

  • An Old Hacker (unregistered) in reply to Frank
    Frank:
    AssBlaster:
    Multiple return points are bad for the same reasons GOTO's are mostly bad. Also, they tend to be used a lot by people who don't know what an exception is.
    And what if you're programming in a language which doesn't have built-in exception handling, like C? I've seen C code which was a horrific tangled mess because the project lead declared that every function must have only 1 return point. As a result, after every function call was an if-structure designed to make sure the calling function would only continue if the called function returned successfully. At the end of each function was a huge pile of closing brackets. God help you if mistakenly deleted an opening bracket a page earlier. The result was code which I found to be very un-maintainable. It really made me say "WTF?"

    Your point is well taken if you are implementing exceptions. But even in a language which supports exceptions natively, exception handling can result in much slower code. Thus, it is often not used in embedded code. In that case, I think multiple return points can actually result in much faster and more maintainable code.

    The really sad part about that is, afaik, in C, there really is only one return point. A return inside the method is implemented as a goto the real return...

  • no u (unregistered) in reply to An Old Hacker
    An Old Hacker:
    The really sad part about that is, afaik, in C, there really is only one return point. A return inside the method is implemented as a goto the real return...

    and in what way is that at all sad?

    The problem with goto's is that developers get confused - not because there is anything actually wrong with the construct

  • Anonymous (unregistered) in reply to boog

    The coding style espoused by TPD mandated all methods be commented, and those comments indicate which methods called the current method.

    I never saw a TPD method comment that was anything more than a list of other method names that could have been more reliably retrieved by tapping Shift-F12 in Studio. There were certainly never any comments about what the method actually did. After all, it should be obvious from the code!

    TPD did like to throw together empty, pointless wrappers (like you suggested there) quite a lot, though.

  • (cs)

    I really love how you pass by ref something that will never change, seriously that string is that long? Oh.. it changes! I realize that I made a lot of WTF when I'm on a hurry, but reinventing the weel deserves a stand up ovation!

  • (cs) in reply to AssBlaster
    AssBlaster:
    Multiple return points are bad for the same reasons GOTO's are mostly bad.
    What reasons might those be, exactly? To be clear, I'm not questioning the reasons GOTOs are bad - but which of these reasons apply to early returns?
    AssBlaster:
    Also, they tend to be used a lot by people who don't know what an exception is.
    So? Many things are probably used a lot by people who don't know what exceptions are: functions, strings, coding libraries, system calls, text editors, operating systems, office chairs, highways, supermarkets, and breakfast cereals, to name a few. Are you saying that therefore all these things are bad too?
  • (cs) in reply to Anonymous
    Anonymous:
    The coding style espoused by TPD mandated all methods be commented, and those comments indicate which methods called the current method.

    I never saw a TPD method comment that was anything more than a list of other method names that could have been more reliably retrieved by tapping Shift-F12 in Studio. There were certainly never any comments about what the method actually did. After all, it should be obvious from the code!

    TPD did like to throw together empty, pointless wrappers (like you suggested there) quite a lot, though.

    It's fine to list methods that call a given method, assuming everyone is capable of keeping such a list up-to-date (many programmers aren't). But my concern was why a search method would ever invoke a replace method.

    I only suggested the pointless wrapper as a guess; my fear is that the real MatchWord makes use of the ChangeWord method in a far more convoluted and sinister way.

  • bye (unregistered) in reply to Frank
    Frank:
    AssBlaster:
    Multiple return points are bad...
    ...Your point is well taken if you are implementing exceptions. But even in a language which supports exceptions natively, exception handling can result in much slower code. Thus, it is often not used in embedded code. In that case, I think multiple return points can actually result in much faster and more maintainable code.
    The early Atari BASIC interpreter was written for the 6502 processor which uses 2 bytes for a short-jump instruction (jump, howfar) but 3 bytes to return from a subroutine call. Since howfar is one byte, it can tell the processor to move to any of 255 locations, from -127 to +128, not counting zero for reasons left as an exercise for the reader.

    So anyway, if you're in the middle of a subroutine and you want to return, you can use 3 bytes to return or 2 bytes to jump to the end of the subroutine and piggyback onto its return instruction.

    If you have several small subroutines all packed into one consecutive 256 byte space, they can all share a single return instruction, with the other subroutines using jumps to exit.

    The mad geniuses who programmed Atari BASIC made generous use of this technique, saving dozens of bytes in total. And they had to, because by the time it was done there were (as I recall) only about 7 leftover unused bytes from the memory allocated to things like this.

  • (cs) 
        // case-insensitive change, convert to UPPERCASE, forget existence of other cultures

    What? Doesn't the library ToUpper() handle this correctly across multiple codepages? Oh, wait, I forgot, the library doesn't have a replace function.

  • (cs) in reply to boog
    boog:
    AssBlaster:
    Multiple return points are bad for the same reasons GOTO's are mostly bad.
    What reasons might those be, exactly? To be clear, I'm not questioning the reasons GOTOs are bad - but which of these reasons apply to early returns?
    He doesn't know, but it must be true because his boss's boss's pimply son (“a real tech genius”) read it in an old Gartner report that someone had printed out and was propping up a wooden table with.
  • (cs) in reply to AssBlaster
    AssBlaster:
    Multiple return points are bad for the same reasons GOTO's are mostly bad. Also, they tend to be used a lot by people who don't know what an exception is.

    Nagesh? Is that you?

  • rfoxmich (unregistered) in reply to Frank

    That was of course because they also outlawed goto as in

    if (someError()) { result = ERROR_CODE; goto done; } ...

    done: return result;

    and similar not so bad goto using patterns...oh wait this is a bit like:

    try { if (someerror()) throw ERROR_CODE; ... } catch (int status) { result = status; } return result;

    captcha transverbero

    Frank:
    AssBlaster:
    Multiple return points are bad for the same reasons GOTO's are mostly bad. Also, they tend to be used a lot by people who don't know what an exception is.
    And what if you're programming in a language which doesn't have built-in exception handling, like C? I've seen C code which was a horrific tangled mess because the project lead declared that every function must have only 1 return point. As a result, after every function call was an if-structure designed to make sure the calling function would only continue if the called function returned successfully. At the end of each function was a huge pile of closing brackets. God help you if mistakenly deleted an opening bracket a page earlier. The result was code which I found to be very un-maintainable. It really made me say "WTF?"

    Your point is well taken if you are implementing exceptions. But even in a language which supports exceptions natively, exception handling can result in much slower code. Thus, it is often not used in embedded code. In that case, I think multiple return points can actually result in much faster and more maintainable code.

  • THE zunesis, as requested (unregistered) in reply to jmucchiello
    jmucchiello:
    // case-insensitive change, convert to UPPERCASE, forget existence of other cultures

    What? Doesn't the library ToUpper() handle this correctly across multiple codepages? Oh, wait, I forgot, the library doesn't have a replace function.

    I can't say enough good things about ToUpper()! An experienced guy like me doesn't always have the energy he had in his 20's. ToUpper() gets me back in the game. Now I'm ready to take the field whenever the moment's right.

    Thanks ToUpper()!

  • THE zunesis, as requested (unregistered) in reply to AssBlaster
    AssBlaster:
    Multiple return points are bad for the same reasons GOTO's are mostly bad. Also, they tend to be used a lot by people who don't know what an exception is.

    Hey man, love the name. But, sadly, you're a fucking idiot. I hope you suffocate on an enormous bull penis.

  • (cs)

    He probably rolled his own ToUpper() too.

  • (cs) in reply to Frank
    Frank:
    AssBlaster:
    Multiple return points are bad for the same reasons GOTO's are mostly bad. Also, they tend to be used a lot by people who don't know what an exception is.
    And what if you're programming in a language which doesn't have built-in exception handling, like C? I've seen C code which was a horrific tangled mess because the project lead declared that every function must have only 1 return point. As a result, after every function call was an if-structure designed to make sure the calling function would only continue if the called function returned successfully. At the end of each function was a huge pile of closing brackets. God help you if mistakenly deleted an opening bracket a page earlier. The result was code which I found to be very un-maintainable. It really made me say "WTF?"

    Your point is well taken if you are implementing exceptions. But even in a language which supports exceptions natively, exception handling can result in much slower code. Thus, it is often not used in embedded code. In that case, I think multiple return points can actually result in much faster and more maintainable code.

    If I find myself writing a method / function / subroutine which demands either multiple returns or a convoluted mess, I take a step back and see whether I might be able to refactor by extracting all the lumps between the returns into separate methods of their own.

    OTOH when I'm doing parameter checks I may well have a few returns up near the top, if for some reason it's inappropriate to throw an exception:

    if (inputParam == null) return;

    ... or whatever.

    There are no unbreakable rules, not even this one.

  • (cs) in reply to bye
    bye:
    The early Atari BASIC interpreter was written for the 6502 processor which uses 2 bytes for a short-jump instruction (jump, howfar) but 3 bytes to return from a subroutine call. Since howfar is one byte, it can tell the processor to move to any of 255 locations, from -127 to +128, not counting zero for reasons left as an exercise for the reader.
    Uh... what? The RTS (return from subroutine) instruction on the 6502 is a single byte. The JMP instruction is three bytes, but why would you be doing a jump to return from a subroutine?

    Besides, if they were really mad geniuses they would have cached the address of the start of each FOR loop, instead of doing a line-by-line search from the start of the program for every. single. iteration.

  • THE zunesis, as requested (unregistered) in reply to lolwtf
    lolwtf:
    He probably rolled his own ToUpper() too.
    That's what I used to resort to. My wife would get frustrated waiting for me to finish rolling. Now I just use ToUpper()!

    [Wife:] "Oh, you're up already? Wow!"

    Thanks, ToUpper()!

  • (cs)

    Oh and it occurs to me why they call it "reinventing the wheel".

    It's because the code so described tends to be in a loop, and it goes round and round and round and round and round and ...

  • AssBlaster Returns (unregistered)

    I'm not saying multiple returns are ALWAYS bad, especially in an embedded system without {insert several unreasonable constraints here}.

    BTW, I don't like this:

    if (catastrophic_failure_that_should_be_logged) return;

//probably someone trying to hack the system. fuck it.
if (!ValidID(user_id)) return;

    I also don't like this:

    if (PassCondition1())
{
   if (PassCondition2())
   {
     if (PassCondition3())
     {
        MagicHappens();
     } else
     {
        //this should not happen. but i guess it did LOL
     }
   } else
   {
      //faiL! LoL
   }   
} else
{
   //failed condition 1 lolz
}

    Inserting a new condition beween 1 and 2 means, at best, re-indenting all that code and at worst getting completely lost.

    As to the guy who asked why are GOTOs bad, well, they are bad because 99% of us aren't trying to write an operating system kernel or paying attention to how much the code is screwing with the CPU's cache in order to shave a few cycles off our 3D game engine.

    Just my 2 cents.

  • Hortical (unregistered) in reply to Matt Westwood
    Matt Westwood:
    Oh and it occurs to me why they call it "reinventing the wheel".

    It's because the code so described tends to be in a loop, and it goes round and round and round and round and round and ...

    Or maybe the phrase was specifically chosen to compare the re-inventor to a caveman - not so much the thing reinvented to the wheel.

  • Rictor (unregistered) in reply to Duke
    Duke:
    If there's one redeeming quality in Java, it's that you can't do half of the things suggested in this wtf.

    // reinvent the troll

    'nuff said.

  • wolf (unregistered)

    My favorite part is the comment 'create a copy - you can't have too many copies'!

  • Cyt (unregistered)

    Ehm... How is this reinventing the wheel? It can do a case-insensitive replace. Does the framework support this? I don't really find this function terrible - heck if I were marking this as an exam-question I'd probably let it pass.

    I am NOT trolling, OK. And for the record, if I was tasked with having to implement this function myself, I'd probably head straight to MSDN for help before starting to reinvent the wheel (to see if the framework supports caseinsensitive replaces)

  • (cs) in reply to AssBlaster Returns
    AssBlaster Returns:
    I'm not saying multiple returns are ALWAYS bad, especially in an embedded system without {insert several unreasonable constraints here}.
    That's all well and good, but when are they bad? I'm not yet convinced they ever are.
    AssBlaster Returns:
    As to the guy who asked why are GOTOs bad...
    I must have missed the comment where the guy asked why GOTOs are bad.
  • (cs) in reply to Hortical
    Hortical:
    Matt Westwood:
    Oh and it occurs to me why they call it "reinventing the wheel".

    It's because the code so described tends to be in a loop, and it goes round and round and round and round and round and ...

    Or maybe the phrase was specifically chosen to compare the re-inventor to a caveman - not so much the thing reinvented to the wheel.

    Yeah yeah yeah but that's just too bleeding obvious to even mention. Doesn't anyone have a fucking sense of humour on this fucking website any more?

  • A Young Hacker (unregistered) in reply to An Old Hacker
    An Old Hacker:
    Frank:
    Your point is well taken if you are implementing exceptions. But even in a language which supports exceptions natively, exception handling can result in much slower code. Thus, it is often not used in embedded code. In that case, I think multiple return points can actually result in much faster and more maintainable code.

    The really sad part about that is, afaik, in C, there really is only one return point. A return inside the method is implemented as a goto the real return...

    @Frank: Exceptions can be used to bypass the call stack, resulting in much faster result in (some) recursive functions. However, I agree that have multiple returns can make the code more readable sometimes.

    @An Old Hacker: Implementation is compiler dependant, not language dependant; and I would be very surprised if compilers like GCC or LLVM implemented it using [i]jmp[\i] to have a single "return point"

  • AA (unregistered) in reply to A Young Hacker
    A Young Hacker:
    I would be very surprised if compilers like GCC or LLVM implemented it using [i]jmp[\i] to have a single "return point"

    If your language has scoping rules such that there's some pretty significant cleanup to be done when returning from a function (running destructors and such), then it's actually pretty likely for a compiler to have that cleanup code in there once and jump to it for every other return, instead of duplicating it for every single point of exit.

  • (cs) in reply to no u
    no u:
    An Old Hacker:
    The really sad part about that is, afaik, in C, there really is only one return point. A return inside the method is implemented as a goto the real return...

    and in what way is that at all sad?

    The problem with goto's is that developers get confused - not because there is anything actually wrong with the construct

    This. Isn't pretty much any branch a JMP instruction anyway? As long as the compiler vendor is the one that has to maintain it, we generally don't give a flying fuck about GOTO.

  • (cs) in reply to Anonymous
    Anonymous:
    The coding style espoused by TPD mandated all methods be commented, and those comments indicate which methods called the current method.

    I never saw a TPD method comment that was anything more than a list of other method names that could have been more reliably retrieved by tapping Shift-F12 in Studio. There were certainly never any comments about what the method actually did. After all, it should be obvious from the code!

    TPD did like to throw together empty, pointless wrappers (like you suggested there) quite a lot, though.

    That only makes sense - barely - for private, protected, and internal methods, where you are expected to have tight coupling.

  • (cs) in reply to A Young Hacker
    A Young Hacker:
    An Old Hacker:
    Frank:
    Your point is well taken if you are implementing exceptions. But even in a language which supports exceptions natively, exception handling can result in much slower code. Thus, it is often not used in embedded code. In that case, I think multiple return points can actually result in much faster and more maintainable code.

    The really sad part about that is, afaik, in C, there really is only one return point. A return inside the method is implemented as a goto the real return...

    @Frank: Exceptions can be used to bypass the call stack, resulting in much faster result in (some) recursive functions. However, I agree that have multiple returns can make the code more readable sometimes.

    @An Old Hacker: Implementation is compiler dependant, not language dependant; and I would be very surprised if compilers like GCC or LLVM implemented it using [i]jmp[\i] to have a single "return point"

    hey zunesis, someone mentioned 'tail recursion'

  • Forcible Entry Expert (unregistered)

    It's funny how Wikipedia lists "Structured Programming" as an alternative to using goto.

  • mtj (unregistered) in reply to Matt Westwood
    Matt Westwood:
    Hortical:
    Matt Westwood:
    Oh and it occurs to me why they call it "reinventing the wheel".

    It's because the code so described tends to be in a loop, and it goes round and round and round and round and round and ...

    Or maybe the phrase was specifically chosen to compare the re-inventor to a caveman - not so much the thing reinvented to the wheel.

    Yeah yeah yeah but that's just too bleeding obvious to even mention. Doesn't anyone have a fucking sense of humour on this fucking website any more?

    Wow. Real irony.

  • (cs) in reply to boog
    boog:
    AssBlaster Returns:
    I'm not saying multiple returns are ALWAYS bad, especially in an embedded system without {insert several unreasonable constraints here}.
    That's all well and good, but when are they bad? I'm not yet convinced they ever are.
    AssBlaster Returns:
    As to the guy who asked why are GOTOs bad...
    I must have missed the comment where the guy asked why GOTOs are bad.
    Mutliple returns are only bad when used by a psychotic code monkey in his ten page long methods with flow control lines jumping around all over like Nightcrawler after he shot the president in X-Men 2. The reason is because it's nigh-impossible to tell which path their shitty code took on its way to ruining your day.

    Developers blessed with The Gift should completely ignore that rule, since it tends to make crystal-clear, well-factored code even clearer, and you'll probably never need to mentally reverse-execute their code anyway.

  • (cs) in reply to Matt Westwood
    Matt Westwood:
    Hortical:
    Matt Westwood:
    Oh and it occurs to me why they call it "reinventing the wheel".

    It's because the code so described tends to be in a loop, and it goes round and round and round and round and round and ...

    Or maybe the phrase was specifically chosen to compare the re-inventor to a caveman - not so much the thing reinvented to the wheel.

    Yeah yeah yeah but that's just too bleeding obvious to even mention. Doesn't anyone have a fucking sense of humour on this fucking website any more?

    You don't think it's funny to call the re-inventor a caveman?

    I thought it was: Ha ha ha!

  • (cs) in reply to hoodaticus
    hoodaticus:
    Mutliple returns are only bad when used by a psychotic code monkey in his ten page long methods with flow control lines jumping around all over like Nightcrawler after he shot the president in X-Men 2. The reason is because it's nigh-impossible to tell which path their shitty code took on its way to ruining your day.
    If there are multiple returns, you're looking for the returns. If there's only one return, you're looking for where the return variable was set. I would wager the two tasks are equally difficult, so I'm still not convinced that early returns are necessarily a bad thing.
    hoodaticus:
    Developers blessed with The Gift should completely ignore that rule, since it tends to make crystal-clear, well-factored code even clearer, and you'll probably never need to mentally reverse-execute their code anyway.
    Or maybe another way to put it: bad design is bad design. If you have a massive, mostly-messy method that also happens to use early returns, it is not a good example of why early returns are bad. The code just sucks. A good example would show how bad code was improved by only removing early returns. I have yet to see such an example myself.
  • (cs) in reply to boog

    You know what? You're right. Multiple returns versus some other penultimate flow control are equally complex to solve. I stand corrected.

    public abstract PervertedComment GetZunesis();
~MyComment() { Console.WriteLine(GetZunesis().ToString()); }

Leave a comment on “The Phantom Duo's ChangeWord”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article