• hmmmm... (unregistered)

    Nothing wrong with responsible use of GoTo in VB6, e.g.

    Private Sub SomeMethod()
    On Error GoTo Catch
    
        'Code here
        
    Exit Sub
    Catch:
        'Handle error here
    End Sub
    

    I've even named the label "Catch" to for all the cough 'real' programmers ;-)

  • (cs) in reply to Al
    Al:
    Wait, is Visual Basic really so crap that goto-ing out of an if-block can cause some kind of leak? Or is the poster just talking out of his ass?

    It's not a documented bug, but if you do a bunch of them and compare to a program that is coded to do the same thing but without the GOTO's, you'll see the speed difference as the GOTO's bog down your system. It's probably not an issue with VB.Net, but having used the other for many years I can attest to having seen this a number of times.

    Addendum (2007-02-23 11:14): References to the compiler and other weird issues in VB's GOTO: http://forums.devshed.com/visual-basic-programming-52/is-goto-safe-416576.html http://visualbasic.about.com/od/imhoinmyhumbleopinion/a/GraGoTo01.htm

  • DKO (unregistered) in reply to TheJasper
    TheJasper:
    E. Dijkstra wrote a short article about the classic goto, and why it is considerd harmful.

    More than 90% of people who cite that Dijkstra's article never read past the title.

    From one of Dijkstra's manuscripts (http://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/EWD1308.html):

    Finally a short story for the record. In 1968, the Communications of the ACM published a text of mine under the title "The goto statement considered harmful", which in later years would be most frequently referenced, regrettably, however, often by authors who had seen no more of it than its title, which became a cornerstone of my fame by becoming a template: we would see all sorts of articles under the title "X considered harmful" for almost any X, including one titled "Dijkstra considered harmful". But what had happened? I had submitted a paper under the title "A case against the goto statement", which, in order to speed up its publication, the editor had changed into a "letter to the Editor", and in the process he had given it a new title of his own invention! The editor was Niklaus Wirth.
  • dolo54 (unregistered) in reply to shambo

    devo r00ls!

  • (cs)

    We code in C and to hide the fact that they used gotos, some developer ages ago decided to do this deep in a common header file: #define _throw goto

    So we would have to write this code something like this:

    #define _else goto

    if (condition)
    {
    	// ... code here
    	_else skipIt;
    }
    
    // more code....
    

    skipIt:

  • (cs) in reply to Will
    Will:
    Harry:
    Frist
    Well done! You misspelled a 5 letter word and didn't even get the first post in. You're a real man now.

    Captcha: RIAA. They're everywhere damnit!

    joke [johk] (noun): something said or done to provoke laughter or cause amusement, as a witticism, a short and amusing anecdote, or a prankish act (source: dictionary.com)

    ;)

  • Anonymous Tart (unregistered) in reply to DKO
    DKO:
    TheJasper:
    E. Dijkstra wrote a short article about the classic goto, and why it is considerd harmful.

    More than 90% of people who cite that Dijkstra's article never read past the title.

    From one of Dijkstra's manuscripts (http://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/EWD1308.html):

    Finally a short story for the record. In 1968, the Communications of the ACM published a text of mine under the title "The goto statement considered harmful", which in later years would be most frequently referenced, regrettably, however, often by authors who had seen no more of it than its title, which became a cornerstone of my fame by becoming a template: we would see all sorts of articles under the title "X considered harmful" for almost any X, including one titled "Dijkstra considered harmful". But what had happened? I had submitted a paper under the title "A case against the goto statement", which, in order to speed up its publication, the editor had changed into a "letter to the Editor", and in the process he had given it a new title of his own invention! The editor was Niklaus Wirth.

    Nothing wrong with gotos innit.

    st0:
        if ( ++p == pe )
            goto out0;
        if ( 48 <= (*p) && (*p) <= 57 )
            goto tr0;
        goto st_err;
    tr0:
        { printf("DGT: %c\n", (*p)); }
    st1:
        if ( ++p == pe )
            goto out1;
        switch ( (*p) ) {
            case 10: goto tr5;
            case 46: goto tr7;
            case 69: goto st4;
            case 101: goto st4;
        }
        if ( 48 <= (*p) && (*p) <= 57 )
            goto tr0;
        goto st_err;
    
  • Minos (unregistered) in reply to Dwayne
    Dwayne:
    ewan:
    I've got this in my vb code. I suppose its lazy but it gets the job done. The alternatives would be complicated nested if blocks, moving existing code out into new functions or having status varibles which you check ie. "if condition occurs status = 'this condition has occured'"

    at the end of the day if you can solve a problem in 5min with 'bad code' its difficult to justify to the business why you should spend a day or two rewriting existing code a better way and probably introducing more errors instead.

    If it takes you a day or two to write an if-else statement, you really don't deserve to be employed anywhere unless it involves the phrase "Do you want fries with that?"

    (Captcha: "ewww". My thoughts exactly.

    Just as long as that job isn't maintainer of the Linux driver for the Sun Happy Meal Ethernet adapter. Excerpt:

    static void happy_meal_tcvr_write(struct happy_meal *hp, 
                                      void __iomem *tregs, int reg, 
                                      unsigned short value)
    {
            int tries = TCVR_WRITE_TRIES;
         
            ASD(("happy_meal_tcvr_write: reg=0x%02x value=%04x\n", reg, value));
    
            /* Welcome to Sun Microsystems, can I take your order please? */
            if (!(hp->happy_flags & HFLAG_FENABLE)) {
                    happy_meal_bb_write(hp, tregs, reg, value);
                    return;
            }
    
            /* Would you like fries with that? */
            hme_write32(hp, tregs + TCVR_FRAME,
                        (FRAME_WRITE | (hp->paddr << 23) |
                         ((reg & 0xff) << 18) | (value & 0xffff)));
            while (!(hme_read32(hp, tregs + TCVR_FRAME) & 0x10000) && --tries)
                    udelay(20);
    
            /* Anything else? */
            if (!tries)
                    printk(KERN_ERR "happy meal: Aieee, transceiver MIF write bolixed\n");
    
            /* Fifty-two cents is your change, have a nice day. */
    }
    
  • David Walker (unregistered) in reply to danixdefcon5
    danixdefcon5:

    Actually, most stupid code comes from Visual Basic ... because Visual Basic itself is a stupid language.

    I know that C# is not the same as C or C++, but VB.NET is almost exactly like C#.NET.

    The same keywords, the same constructs, the same capabilities, and often the same intermediate-level code gets generated as an equivalent C# program would generate. Which means it runs as fast as the same code written in C#.

    VB.NET has try/Catch/Finally; it has collections and the ForEach statement; it has inheritance and base classes and derived classes; you can create your own constructors and destructors in your base and derived classes; it handles events; it has interfaces and Implements; it has Public/Protected/Private/Shared/Friend/Static; it has overloads; it has CreateObject; you can make a nonvirtual call to a virtual method of the current object; you can declare a partial definition of a class or structure; it has delegates; and it has threading primitives.

    VB.NET is not a "toy" language nor a "stupid" language.

  • (cs) in reply to Thunderbird

    I wish I didn't see this all the time in some code I'm "updating" at work, but sad to say I do. To make it worse, the code I'm working on is a bizarre mix of C and C++! Yuck!

  • ionous (unregistered) in reply to TSK
    TSK:
    Ok, I am outing myself:

    Once upon a time I coded in C++. I had to intercept key/menu commands which were interrelated (like direction commands of the up/down/left/right key); I will call them blocks. There were several such blocks in the code. In all there were 5 blocks of 3-5 commands (~20 commands) with 1-2 lines setting the variables and then doing always the same routine (3-4 lines) in the block. I wasn't interested in function pointers because it felt like breaking a fly on the wheel.

    And I am still convinced that it ISN'T bad....

    It's things like that, that make me wish c/++ had anonymous functions available.

    At any rate, seems like you probably could have wrapped up those goto blocks in small sub-functions, and just called the sub-functions from the case statements....

    note: even w/o function pointers you could do:

    struct Pos { int x, int y }; struct MoveCmd { int key, Pos delta }; MoveCmd MoveCmds { { UP, { 0, 1} } , { DOWN, {0, -1 }} , { LEFT, { -1,0 } }, { RIGHT, {1, 0 }} }; struct ZoomCmd { int key, int z }; ZoomCmd zoomcmds { { ZOOM, -1 }, { SHRINK, 1 } };

    bool handled=false;

    for ( i=0; i< sizeof(movecmds); ++it ) { MoveCmd* cmd= movecmds+i; if ( handled= (key == cmd->key)) { bool ok = testIfOutOfBounds(cmd->delta); if (ok) { // move . . . } break; } } if (!handled) { // similar zoom code . . . } assert(handled); if (!handled) { // error . . . };

    which would easily allow you to add diagonal keys, undo, redo tracking, etc. =>

  • Alex Brown (unregistered) in reply to Alky

    Are you kidding? You almost got me. Had this been slashdot, you would have been flamed...now.

    I swear - I typed that then looked at my CAPTCHA: slashbot. What a freaking weird coincidence.

  • Alex Brown (unregistered) in reply to Alex Brown

    That comment was directed at Alky. I thought it automatically quoted when replying...

  • (cs) in reply to Alex Brown
    Alex Brown:
    That comment was directed at Alky. I thought it automatically quoted when replying...

    Only if you use the "Quote" button, instead of the "Reply" button.

  • bramster (unregistered) in reply to danixdefcon5
    danixdefcon5:
    mav:
    It seems to me, from reading these forums, that visual basic is all OVER the place. Or perhaps more stupid code is created for visual basic. That'd be an interesting question to get some stats on...

    Captcha: Kungfu

    Actually, most stupid code comes from Visual Basic ... because Visual Basic itself is a stupid language.

    M$ screwed up generations of developers by nudging these atrocities, and then try to fix it with C#. Too bad they threw in VB.net, enabling awful code to remain in their shiny-new enterprisey platform.

    I wish I still had one of my former collegemate's source code for a "non-LIFO" stack in VB ... go figure what that was used for.

    non-LIFO -- FIFO FILO PUFO

    PUFO is for gotos. Pick up and F*ck Off

  • wtf (unregistered)

    3 of the 4 screw-ups that the submitter talks about are one and the same (not using else = logical flow issues = reduced legibility)

    the remaining one is a non-issue - abnormal exit, wtf? memory/compiler issues, wtf? in what kind of interpreter/compiler are there issues with jumping out of an if block? does the submitter actually think this code would ever run in any other interpreter except what it was coded for? ok, well, to be fair perhaps it might some day run on the next version of the same interpreter, but it is quite certain that there will be no problems with that.

    granted, the snippet is a wtf. the coder obviously wasn't familiar with such VB basics like the else statement. he probably had experience with other languages, i.e. assembler or, for what it's worth, the original BASIC language where there is no construct like else and a similar use of jump/goto is in fact the proper way to code this.

    but the submitter's comments are even a bigger wtf in the way they're trying to present this as more than it actually is. can't figure out "where we skipped here from"? gee, a search for that label is too hard... perhaps you'd have preffered a "comefrom" statement to clarify things for you?

  • Faxmachinen (unregistered) in reply to TheJasper
    TheJasper:
    !goto:
    Programmer who uses a goto construts must burn in Hell.
    well, I thin we have to excuse assembly programmers, it would make life difficult otherwise.
    And Batch programmers. If you can even call them that.
  • TSK (unregistered) in reply to ionous

    It's things like that, that make me wish c/++ had anonymous functions available.

    Yep, so I am currently trying to learn OCaml...

    At any rate, seems like you probably could have wrapped up those goto blocks in small sub-functions, and just called the sub-functions from the case statements....

    Yes, but it means that I write a sub-function for three-four instructions. These subfunctions have the disadvantage that they must be repeated in each case and must be followed by a break instead of a goto. They are awfully small and they are separated from the main code.

    note: even w/o function pointers you could do:

    You mean data pointers ? (I don't see a function) No offense meant, but I think the pointer solution is inferior in this particular case:

    a) You must allocate several structures to mimic a simple assignment.

    b) I mentioned that there more than two cases in the routine ; in the example I wrote they are indicated by ... So you can't use an if; you must use either a switch or if/elseif - cascade.

    c) The main code remains in one place in the switch-goto solution in contrast to the structs and pointers.

    There is simply no reason in this particular case to use not this solution; if the blocks were bigger or the number of cases higher (>30) I admit your solution would be preferable. The goto hate is quite irrational; since four years I have needed it only two times, but when I need it, it is indispensable.

  • Mike5 (unregistered)

    I see nothing wrong with that... All ZX Spectrum program were written using GOTOs. In those days we didn't have all this fancy stuff like "else" keywords. Those are for pussies!

    Catcha: dubya - not again!!!!

  • (cs) in reply to TheJasper
    TheJasper:
    Return, break and continue aren't goto statements because it's fairly clear where you're coming from and where you're going to. This is an important distinction.

    What?

    As opposed to gotos, where it's not at all clear where you're coming from and where you're going to?

  • verisimilidude (unregistered)

    Obviously the writer was an old Fortran IV programmer that had never really accepted this new-fangled block programming.

    The only target for an IF was a single statement, so you usually used a GOTO. The following line was therefore the ELSE and you would have to search the code to find the label to THEN. Of course both of those 'blocks' would terminate with another GOTO, hopefully further down but in a WTF program could well be somewhere in the series of statements being executed in the branch.

  • Harrow (unregistered) in reply to BF
    BF:
    crapocity? I love the new vocabulary I pick up on this site </smiles>
    Crapocity is, of course, derived from the words "crap" (crapula, craptastic), and "velocity" (starring Keanu Reeves and Sandra Bullock). VB is reknowned not so much for the ubiquity of the crap written it (I think ASP has that lead) as it is for the astounding rate at which enormous mounds of steaming ordure appear behind a VB dev team. The language supports and encourages developing bad code real fast; hence, "crapocity".

    -Harrow.

  • ching_tow (unregistered)

    Most developers don't understand how many stupid VB developers there are. Ease of syntax has allowed the barbarians in the gate. I used to work for a company where the product's central business-critical task was all done within the click event of a button. The code was 150 printed pages with enormous "IF" blocks. Everything was indented just 1 or 2 spaces. It was full of GOTOs, arbitrarily named variables, multi-dimensional arrays with cryptic names (e.g. If q(3,7,2) = "a" then goto sch_cal_1). Although the "core" development team (core meaning not smart enough to get a job elsewhere) had been there 3-5 years, one of them didn't even own a PC at home. None of them even knew how to create a dll, much less understood when/why to use them. Both claimed to have degrees from universities in far distant lands --- one even claimed to have a masters in mathematics. The surest way to get hired was to say "I'll do the job for $50K" when the position was advertised at $65K. And the "got the company from my mommy" CEO couldn't figure out why his product sucked so bad --- stupid beeyoch!!!

  • Bill Trent (unregistered) in reply to BF
    BF:
    I vaguely remember my basic programming days... Some OS360 hotshot programmer tried to explain to me how you should do stuff like this:
    10 $A = 400  ;; create a computed goto target
    ;; lots of intervening crap
    200 goto $A
    210 stop
    ;; more unrelated crap
    400 ' target of goto
    

    and his code was riddled with stuff like this.

    I'm not sure what evil breed of BASIC that's coming from, but it reminded me of the ON ... GOTO ... instruction in BASICA or GW-BASIC.

    Neither BASICA nor GW-BASIC allow the statment you've quoted. That is, this is not a valid BASICA program:

    10 PRINT "Hello. Enter choice (1-9): "; 20 INPUT V% 30 V% = (VAL(X$) + 4) * 10 40 IF V% > 40 THEN GOTO V% 45 PRINT "Invalid. Enter number (1-9): "; 47 GOTO 20 50 PRINT "You chose 1" 55 GOTO 150 60 PRINT "You chose 2" 65 GOTO 150 70 '... etc. . . . 150 END

    Instead, you would do this:

    10 PRINT "Hello. Enter choice (1-9): "; 20 INPUT V% 30 ON V% GOTO 40,50,60,70,80,90,100,110,120,130 40 PRINT "Invalid. Enter choice (1-9): "; 45 GOTO 20 50 PRINT "You chose 1" 55 GOTO 150 60 PRINT "You chose 2" 65 GOTO 150 70 '... etc. . . . 150 END
  • Bill Trent (unregistered) in reply to Harrow
    Harrow:
    VB is reknowned not so much for the ubiquity of the crap written it (I think ASP has that lead) as it is for the astounding rate at which enormous mounds of steaming ordure appear behind a VB dev team.

    I might be wrong, but I thought that VB was the primary language used to write ASPs. As such, I don't understand this sentence.

  • Bill Trent (unregistered) in reply to Bill Trent

    Ack. Sorry about the odd "VAL(X$)"... here's the syntax-error-free version:

    Bill Trent:
    10 PRINT "Hello. Enter choice (1-9): "; 20 INPUT V% 30 V% = (V% + 4) * 10 40 IF V% > 40 THEN GOTO V% 45 PRINT "Invalid. Enter number (1-9): "; 47 GOTO 20 50 PRINT "You chose 1" 55 GOTO 150 60 PRINT "You chose 2" 65 GOTO 150 70 '... etc. . . . 150 END
  • (cs) in reply to Al
    Al:
    Wait, is Visual Basic really so crap that goto-ing out of an if-block can cause some kind of leak? Or is the poster just talking out of his ass?

    it does in TI-BASIC, though that's a different language.

    considering you don't have functions or (working) subroutines, that forces you to use single-statement-ifs-plus-gotos all over the place.

  • waefwaefk (unregistered)

    Meh. I used to see this sort of crap all the time. I used to work with a poser VB programmer, and his coding was terrible. If it was as bad as this, I would've been an improvement.

    His next language was ColdFusion, and the clusterf*cks he did in that platform was akin the killing fields of Vietnam, such was the horror.

  • (cs) in reply to foo
    foo:
    akatherder:
    I thought most languages separated gotos and conditionals as much as possible. Just think if you jumped into the middle of a while loop or an if-statement. Most languages find it just as offensive to jump out.

    Simon Tatham's coroutine macros (in C) uses a switch to jump into a for loop. http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html

    So does the original Duff's Device (well jumps inside of a do loop, really). Tom Duff was also slightly dubious about the construct, so he asked Dennis Ritchie if this was legal C who endorsed it.

    And the best thing is that thanks to Google Groups you can actually read the original post

  • Michael (unregistered) in reply to mrprogguy
    mrprogguy:
    if(testFailed) return A; else return B;
    This wouldn't even compile, as the else doesn't belong to the if block in question, and it cannot belong to an if block outside of the code you showed (either of which would be finished by the return statement in the shown if block's true block, due to the ; following the return).

    If you're going to want people on TDWTF to explain something, it helps to get it right.

    CAPTCHA: gotcha

  • KM (unregistered) in reply to Michael
    Michael:
    mrprogguy:
    if(testFailed) return A; else return B;
    This wouldn't even compile, as the else doesn't belong to the if block in question, and it cannot belong to an if block outside of the code you showed (either of which would be finished by the return statement in the shown if block's true block, due to the ; following the return).

    If you're going to want people on TDWTF to explain something, it helps to get it right.

    CAPTCHA: gotcha

    ...

    Please tell me this is some kind of elaborate joke that I don't get. Otherwise, please learn basic C syntax before you try to criticize others.

  • SmashAndGrab (unregistered)

    As Marshall Cline says "Goto's are evil."

    I have only used one once, and that was due to a poor design decision in the beginning. Not my decision, but one I was constrained to. I coded it, and then left before I got fired for the results.

  • Abscissa (unregistered) in reply to Bill Trent
    Bill Trent:
    Harrow:
    VB is reknowned not so much for the ubiquity of the crap written it (I think ASP has that lead) as it is for the astounding rate at which enormous mounds of steaming ordure appear behind a VB dev team.

    I might be wrong, but I thought that VB was the primary language used to write ASPs. As such, I don't understand this sentence.

    Not exactly. ASP (primarily) uses VBScript, which is a dumbed-down version of pre-.NET VB. VBScript is such an atrocity it makes VB6 look GOOD.

  • Aaron (unregistered) in reply to Ralf Engels
    Ralf Engels:
    No. In principle you have enough goto's in every current language. "break" "continue" (also called "next" sometimes) and don't forget "return" which is often used to jump out of a subroutine.

    Don't get me wrong. I don't hate those, but in principle those are also goto's.

    So, you're admitting outright that you don't understand the difference between general flow control and "goto"?

    That's the same as saying that every if/then/else construct is actually a "goto". Technically, at the machine level, that's what it looks like, but the point of a high-level language is that we really don't care what the low-level instructions look like.

  • Joseph Newton (unregistered) in reply to Ralf Engels
    Ralf Engels:
    No. In principle you have enough goto's in every current language. "break" "continue" (also called "next" sometimes) and don't forget "return" which is often used to jump out of a subroutine.

    Don't get me wrong. I don't hate those, but in principle those are also goto's.

    I think you're missing the point. Under the surface, a function call is also a goto. Actually, any flow-control construct is a goto, in a way. Neverthelsss, modern programming languages have provided high-level constructs that take the label [or line-number] tracing out of the equation and allowed for logical flow.

    The commands break, continue, next, and Perl's last can all certainly be misused, as any programming construct can. they can also be put to very good use. Generally, good compilers will issue a warning if these are used in predictably perverse ways.

    Explicit gotos are relics of a prior century, and should be relegated to the Museum of Obsolete Technology.

  • StructuredToRupture (unregistered) in reply to DKO
    DKO:
    More than 90% of people who cite that Dijkstra's article never read past the title.

    Feel free to read Dijkstra's article in its entirety. Please, for the sake of the sanity of maintenance programmers worldwide.

    The article was first published almost 40 years ago in 1968, and people are still using GOTO? Dijkstra must be rolling in his grave.

  • A good workman (unregistered) in reply to hmmmm...
    hmmmm...:
    I refer you to the common phrase "A bad workman blames his tools".
    Which, like most common phrases, is only half true. Even if it is true that bad workmen blame their tools, it does not follow that everyone who blames his tools is a bad workman.
    The trouble with VB is that it's easy for an idiot to produce 'something' and call himself a programmer
    That's one problem. The other problem is that VB (of the VB6 variety, not Visual Fred.Net) isn't expressive enough for anyone who isn't an idiot to write good code. Case in point: the utterly stupid "On Error" error-handling system, which basically enforces the use of spaghetti code.
  • Icelight (unregistered) in reply to Alkari
    Alkari:
    Me, I'm a fan of including a few goto labels at random in the code. No gotos, of course, just the labels. Even though they're completely meaningless, I know there's a pleasing pulse of oh-geez-what-does-this-do coming up the next time someone looks at the code...

    Most people would call those 'comments', generally most languages have them available...

  • (cs) in reply to Joseph Newton
    Joseph Newton:
    Explicit gotos are relics of a prior century, and should be relegated to the Museum of Obsolete Technology.

    There are still PLENTY of uses of goto that are quite reasonable. It's used all over OS kernels for instance to do error handling because there alternatives are worse.

    Here is it with gotos:

      p = allocate();
      if(!p) goto out_p;
      q = allocate();
      if(!q) goto out_q;
      r = allocate();
      if(!r) goto out_r;
    
      dostuff(p,q,r);
      return IM_HAPPY;
    
    out_r:
      deallocate(q);
    out_q:
      deallocate(p);
    out_p:
      return IM_SAD;
    

    Here it is without gotos:

      p = allocate();
      if(p) {
        q = allocate();
        if(q) {
          r = allocate();
          if(r) {
            dostuff(p,q,r);
            return IM_HAPPY;
          }
          deallocate(q);
        }
        deallocate(p);
      }
      return IM_SAD;

    Which is more readable? It's probably a style choice and not a clear win, but option #2 seems to be preferred by most people.

    I have another use for goto that I'm doing right now that I don't want to get into that would work similarily.

  • (cs) in reply to Icelight
    Icelight:
    Alkari:
    Me, I'm a fan of including a few goto labels at random in the code. No gotos, of course, just the labels. Even though they're completely meaningless, I know there's a pleasing pulse of oh-geez-what-does-this-do coming up the next time someone looks at the code...

    Most people would call those 'comments', generally most languages have them available...

    What?

    Generally comments don't make me go "I wonder how this affects the program's execution"...

  • waefwaefk (unregistered)

    The main issue is that there is no real reason to use goto in VB6. In fact, there's no reason to have goto in VB6. It's there because the original MS BASIC had goto.

  • ewan (unregistered)

    pah, using goto is fine if it solves the problem at hand. Its hardly a wtf realy. Sure if your starting from scratch you should avoid bad technique like this, But when the business wants that change now now now! (theres all ways a big deal to close if the colour can just be pink) then you have to do what you can to make it work with minimun change to the existing code. Not go off on a rant about you will have to refactor the entire code base to your fave OO methodolgy.

    The customer wants fries Now! not made in an easier to maintain fryer next week. I've made the sale and you guys are spending money on a new fryer no-one wants.

  • waefwaefk (unregistered) in reply to ewan
    ewan:
    pah, using goto is fine if it solves the problem at hand. Its hardly a wtf realy. Sure if your starting from scratch you should avoid bad technique like this, But when the business wants that change now now now! (theres all ways a big deal to close if the colour can just be pink) then you have to do what you can to make it work with minimun change to the existing code. Not go off on a rant about you will have to refactor the entire code base to your fave OO methodolgy.

    The customer wants fries Now! not made in an easier to maintain fryer next week. I've made the sale and you guys are spending money on a new fryer no-one wants.

    You know, it's actually possible to come up with a decent solution that gasp takes the same time as the bad solution.

    I've worked with morons like you that just spit out code that works like crap. And know what? I finish the stuff I write that's actually maintainable BEFORE they do. It's amazing how they trip over themselves fixing code they can't even comprehend that they wrote the day before. Yeesh.

  • pc486 (unregistered)

    This is not a post condoning the use of goto's in this case, but if the VB compiler is any good then the use of a goto here shouldn't cause memory or compiler issues.

    For those who remember your compiler class and can recall how to create basic block graphs, give it a try for this example. You'll notice the difference between the if-else graph and a if-skipit graph is a change of one node's follow arrow to a branch arrow. A good compiler can cope with this situation without using extra memory or getting stuck in some difficult graph optimization algorithm.

    Now, if the compiler for VB 6 or VB.Net is any good is a different issue entirely :-). Anyone willing to test and benchmark them?

  • Phil Walker (unregistered) in reply to waefwaefk
    waefwaefk:
    You know, it's actually possible to come up with a decent solution that *gasp* takes the same time as the bad solution.

    I've worked with morons like you that just spit out code that works like crap. And know what? I finish the stuff I write that's actually maintainable BEFORE they do. It's amazing how they trip over themselves fixing code they can't even comprehend that they wrote the day before. Yeesh.

    And gasp it's possible to write useful, easy-to-maintain code utilizing the benefits of GOTO.

    If you comment your code, then whatever solution can be easy to maintain. It's true that mixing GOTO with an OO solution probably isn't a good mix. But if you're dealing with primarly iterative code, it can actually be easier to understand with GOTO and descriptive labels than we code blocks. One can argue for functions, but how much different is a function from a GOTO anyway?

    totalCost = unitCost * quantity; if(totalCost > 25) goto freeShipping; // or doFreeShipping(); else goto addShipping; // or doAddShipping;

    So long as the code that freeShipping and doAddShipping refers to jump to the same place at the end, there's not much difference. And when you get down there and you see:

    addShipping: // Calculate shipping costs; jumps from the beginning of calculatePrice

    These aren't inherently horrible uses. More modern structures are more natural for many situations (including my example), but occasionally GOTOs work even better. Especially in languages that do not allow multiple function return points; using GOTO you can simulate that behavior.

  • creaothceann (unregistered) in reply to KM
    KM:
    Michael:
    mrprogguy:
    if(testFailed) return A; else return B;
    This wouldn't even compile, as the else doesn't belong to the if block in question, and it cannot belong to an if block outside of the code you showed (either of which would be finished by the return statement in the shown if block's true block, due to the ; following the return).

    If you're going to want people on TDWTF to explain something, it helps to get it right.

    CAPTCHA: gotcha

    ...

    Please tell me this is some kind of elaborate joke that I don't get. Otherwise, please learn basic C syntax before you try to criticize others.

    AHAHAHA!!! Another one who didn't get it!! :)))

    Captcha: craaazy

  • ewan (unregistered) in reply to waefwaefk
    waefwaefk:
    I've worked with morons like you that just spit out code that works like crap. And know what? I finish the stuff I write that's actually maintainable BEFORE they do!!! god!

    yeah yeah, talk to the hand girl friend! I know your beardy coding style, you'll spend years working out the perfect system that can never go wrong and then throw a linux fit when a real business need comes along that you haven't thought of because you'll have to change your precious model to fit it in.

    Then you'll make up stuff like 'maintainablity', 'documentation' and 'testing' to justify why the guy next doors 2min fix isn't good enough when the customer is happy and shelling out for it!

    At the end of the day money talks, make it work the simplest and quickest way you can, refactor later if nessecary.

  • creaothceann (unregistered) in reply to ewan
    ewan:
    waefwaefk:
    I've worked with morons like you that just spit out code that works like crap. And know what? I finish the stuff I write that's actually maintainable BEFORE they do!!! god!

    yeah yeah, talk to the hand girl friend! I know your beardy coding style, you'll spend years working out the perfect system that can never go wrong and then throw a linux fit when a real business need comes along that you haven't thought of because you'll have to change your precious model to fit it in.

    Then you'll make up stuff like 'maintainablity', 'documentation' and 'testing' to justify why the guy next doors 2min fix isn't good enough when the customer is happy and shelling out for it!

    At the end of the day money talks, make it work the simplest and quickest way you can, refactor later if nessecary.

    Um... "maintainable code" is a different issue than "perfect system".

    His point is that maintainable code can be changed faster than unmaintainable code (which results from unrestricted GOTO).

    For the record, there's only one situation where you need GOTO: leaving nested loops immediately. And even then the language could make it unnecessary:

    For y = 0 to 15 do For x = 2 to 57 do If (a <> b) then Break(y);

  • brendan (unregistered)

    I've yet to see an example that is impossible to not use goto.

    Even jumping out of two nested loops.

    for(int x = 0;x < 100;++x) for(int y =0;y < 200;++y) if ((x == 50) && (y == 50)){ //Some code goto skipIt } skipIt: // Some code

    Can be refactored into this

    void Find5050(){ for(int x = 0;x < 100;++x) for(int y =0;y < 200;++y) if ((x == 50) && (y == 50)){ //Some code return; } }

    ...

    Find5050(); // some code

    If someone can come up with an example, I would like to know.

  • Eric (unregistered)
    Explicit gotos are relics of a prior century, and should be relegated to the Museum of Obsolete Technology.
    A true professional knows when to use gotos and when not to use gotos.

    In some cases, a judiciously placed goto can be by far the cleanest method of exiting from a set of nested if ... then structures. Instead, second rate programmers will often make their code nearly unreadable trying to avoid using a goto.

    Another good use is as a common exit point from a function. For example, should you have a number of open files to close and more than one return, you have to close all the open files at each return. Instead, a simple goto to a common set of code and you only have one place to close all the files. It is not only cleaner, but it is more understandable as well.

    Sure, gotos can easily be abused. But refusing to use them at all because you think they are somehow uncool is nothing but another form of self abuse.

Leave a comment on “When A Problem Comes Along, You Must skipit”

Log In or post as a guest

Replying to comment #:

« Return to Article