• Thunderbird (unregistered)

    Perhaps

  • (cs)

    "hmmm... wonder where we skipped here from?"

    This is, of course, why INTERCAL's COME FROM statement is so useful.

    removes tongue from cheek

  • Claire (unregistered)
    <sarcasm> Nice. Programming is always so dull without some good old-fashioned spaghetti code.

    These days I have to rely on enormous, end-user-created Excel spreadsheet "databases" to satiate my appetite for variables with no relevant naming and heaps of barely-traceable goto statements.
    </sarcasm>

  • Al (unregistered)

    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?

  • (cs)

    Here's what happened.

    The code was originally written without the if-statement and the SkipIt label. They suddenly had a need for a very specific case that they needed to take into account. Some old fart assembly programmer didn't know how to write a proper if/else statement but he remembered gotos. So he added the new condition and goto to skip the original code.

  • (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?

    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.

  • mav (unregistered) in reply to akatherder

    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

  • A. Skrobov (unregistered) in reply to Al

    the latter

  • (cs) in reply to akatherder

    When a problem comes along. You must skip it. If the code becomes too long. You must skip it. When something's going wrong. You must skip it.

    try to detect it. it's not too late. to skip it. skip it good.

  • Ralf Engels (unregistered) in reply to akatherder
    akatherder:
    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?

    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.

    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.

  • JD (unregistered) in reply to shambo
    shambo:
    When a problem comes along. You must skip it. If the code becomes too long. You must skip it. When something's going wrong. You must skip it.

    try to detect it. it's not too late. to skip it. skip it good.

    Thank you! That made my morning!
  • (cs)

    This is nothing! Here's what I deal with on a regular basis.

    Sub ClearUserMenu()
' 08/28/2006 xxx removed mnuMenuSelect(icnt).unload because it doesn't work in a combo box event
    Dim iCnt As Integer
    Dim sTemp As String
    
    On Error GoTo LastUserMenuItem

LastUserMenuItem:
    On Error GoTo Err_ClearUserMenu
    For iCnt = frmHFW20.mnuMenuSelect.Count - 1 To 1 Step -1
        frmHFW20.mnuMenuSelect(iCnt).Caption = ""
    Next iCnt

Exit_ClearUserMenu:
    Exit Sub
    
Err_ClearUserMenu:
    ProcName = "ClearUserMenu"
    GenErr
    Resume Exit_ClearUserMenu
End Sub

    And that's when the sub is not over 800 lines long.

  • jweller (unregistered)

    I don't know any VB. Does the compiler provide any warnings like C/C++?

  • !goto (unregistered)

    Programmer who uses a goto construts must burn in Hell.

  • Will (unregistered)
    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!

  • (cs) in reply to jweller
    jweller:
    I don't know any VB. Does the compiler provide any warnings like C/C++?

    No. Not like C++. You mean the warning of multiple exit points etc. No nothing like that all.

  • (cs) in reply to akatherder

    Visual Basic is very clear about when and where you can use goto:

    GoTo can branch only to lines within the procedure where it appears.

    You cannot use a GoTo to branch from outside a For...Next, For Each...Next, SyncLock...End SyncLock, Try...Catch...Finally, or With...End With block to a label inside.

    Within a Try...Catch...Finally construction, you cannot use GoTo to branch out of a Try block, into a Catch block, or into or out of a Finally block. You can branch from a Catch block into the Try block associated with that Catch. For example, if one Try...Catch...Finally construction is nested within another, a Catch block can branch into the Try block at its own nesting level, but not into any other Try block.

    Jumping out of an if cannot be a problem for VB because otherwise the standard (olde worlde) practice of:
    If Condition then GoTo LineA Else GoTo LineB
    would be a problem

  • Unomi (unregistered)

    Maybe it's just a dialect / accent problem. One programmer wannabe asked the other how to solve a string matching task. The other just replied: "You've got to escape it". Not eager to ask anymore questions, the lamer thought he understood it as "You've Goto SkipIt". After inserting this line it broke the code even worse. Finally he found the solution: he forgot to use the label "SkipIt". And it worked.

    Captcha: kungu is being spelled in many dialects differently

    • Unomi -
  • (cs) in reply to shambo
    shambo:
    When a problem comes along. You must skip it. If the code becomes too long. You must skip it. When something's going wrong. You must skip it.

    try to detect it. it's not too late. to skip it. skip it good.

    LOL! That is definitely going on my huge whiteboard.

  • (cs) in reply to shambo
    shambo:
    When a problem comes along. You must skip it. If the code becomes too long. You must skip it. When something's going wrong. You must skip it.

    try to detect it. it's not too late. to skip it. skip it good.

    Or:

    If a problem comes along, Go to skip it?

  • (cs) in reply to GettinSadda
    GettinSadda:
    Visual Basic is very clear about when and where you can use goto:
    GoTo can branch only to lines within the procedure where it appears.

    You cannot use a GoTo to branch from outside a For...Next, For Each...Next, SyncLock...End SyncLock, Try...Catch...Finally, or With...End With block to a label inside.

    Within a Try...Catch...Finally construction, you cannot use GoTo to branch out of a Try block, into a Catch block, or into or out of a Finally block. You can branch from a Catch block into the Try block associated with that Catch. For example, if one Try...Catch...Finally construction is nested within another, a Catch block can branch into the Try block at its own nesting level, but not into any other Try block.

    Jumping out of an if cannot be a problem for VB because otherwise the standard (olde worlde) practice of:
    If Condition then GoTo LineA Else GoTo LineB
    would be a problem

    You're talking about VB.NET which is a very different language all together. Try Catch does not exist in VB. I just slapped this together in VB 6.0 and it ran just fine.

    Private Sub Form_Load()
    Dim ctr As Integer
    
    For ctr = 0 To 10
        
        If ctr = 5 Then
            GoTo MessageBox
        End If
        
    Next
    
    Exit Sub
    
MessageBox:
    MsgBox "GoTos really do suck and are abused!"
        
    GoTo forloop
    
    For ctr = 0 To 20
        If ctr = 3 Then
            
forloop:
            MsgBox ctr
        End If
    Next
    
End Sub

    Edit: Ooooo yuck! This is the most hideous code I have ever writen. Oh my God this is gruesome.

  • ewan (unregistered)

    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.

  • (cs)

    Thousand-line functions? Meh. Some of the more monolithic modules I've worked on have been far exceeding that, though they were mostly put into functions for cosmetic reasons only anyhow -- it was just something like:

    DoThing1(); DoThing2(); DoThing3(); DoThing4();

    You could break them up further so as to bring the LOC count down for each individual function, but it still would've had more or less the same end result.

  • (cs) in reply to mav
    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

    Both are true. The main thing about VB is that it has fewer "barriers to entry" than most other languages, meaning that it is easier to start using the language if you have no programming experience. This basic aspect of the language meant that a lot more people started using it in the 90s (hence VB code's ubiquity), and a lot more people used it badly (hence the high level of VB code's crapocity).

  • foo (unregistered) in reply to akatherder
    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

    This trickery is, as far as I understand, used in Putty to implement the SSH protocol.

  • (cs) in reply to shambo
    shambo:
    When a problem comes along. You must skip it. If the code becomes too long. You must skip it. When something's going wrong. You must skip it.

    try to detect it. it's not too late. to skip it. skip it good.

    Yay, a Devo parody!

  • hmmmm... (unregistered) in reply to mav
    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...
    I refer you to the common phrase "A bad workman blames his tools".

    The trouble with VB is that it's easy for an idiot to produce 'something' and call himself a programmer, the problem is compounded when the idiot gets employed by a naive/ignorant company to write production code !

  • (cs) in reply to GettinSadda
    Ralf Engels:
    akatherder:
    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?

    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.

    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.

    when people speak of goto, they usually are thinking of being able to jump to any place in the code. If that was possible, then yes, it could lead to leaks, logic errors segmentation faults and even the end of civilisation as we know it. This is not quite the case however (see below, though I admit I don't know VB so I only assume what is said about it).

    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.

    GettinSadda:
    Visual Basic is very clear about when and where you can use goto:

    So basically VB goto isn't the goto we all (should) avoid. Why they would then even use that name is beyond me...

    E. Dijkstra wrote a short article about the classic goto, and why it is considerd harmful. This is of course about the classic goto statement which allowed you to jump to any arbitrary point in the program. If you don't understand why this is harmfull you are either a beginning student or unsuited to the IT profesion.

  • (cs) in reply to ewan
    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.

    That is because you can not think past your next nap. You are lazy. When you use GoTos in your code, your code becomes a little more difficult to maintain. That function will not stay the way it's written today forever. It's only a matter of time before someone else (or you) has to come in and modify the GoTo code. Five or six edits later with 8 or 9 extra GoTos will make the code bulky and eventually very buggy.

    Most of a programmers time is spent maintaining code. Therefore it would make since to write your code so that it is easy to maintain. The 5 minutes that you save today may take someone an additional 10 minutes if they want to add on to your functions at a later date. This may in turn take 20 minutes for someone else down the road.

    There have been many smarter and more experianced people before us that preach to us to not write code "the bad way" for a reason. That's because rather then at the end of the day, but at the end of the life cycle of the application, good written code can be changed much faster then bad written code.

    PS: Sorry about the lazy comment. I'm gettting a chance to blow off steam. I don't think you're lazy...I don't even know you. I doubt someone who admits that they might be lazy really is lazy.

  • (cs) in reply to Thunderbird

    I'm still waiting for someone to explain this construct (found in K&R, even):

    if(testFailed) return A; else return B;

    I reaaally don't understand how protecting a return with an else is useful.

  • TSK (unregistered)

    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. So I did:

    int x = 0, y = 0, z = 0;

    switch(key) { //--------- BLOCK1 (moving) -------------- case UP: y = 1; goto block1: case DOWN: y = -1; goto block1: case LEFT: x = -1; goto block1: case RIGHT: x = 1; // ------- BEGIN BLOCK 1 routine ------------- block1: bool ok = testIfOutOfBounds(x,y); if (ok) { move(x,y); protocolXY(x,y); } break;

    //-------- BLOCK2 (zooming) ---------------- case ZOOM: z = -1; goto block2: case SHRINK: z = 1; // ------- BEGIN BLOCK 1 routine ------------- block2: bool ok = testObjectDistance(z, incDistance); if (ok) zoom(z, incDistance); break; .... default: assert(false); throw COMMAND_HANDLER_ERROR; }

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

  • dww (unregistered)

    As already intimated, the solution to this is the famous COME FROM statement, as described by R. Lawrence Clark in his paper of 1973, which I'm sure you have all read. (It was required reading for that test you passed.)

    More seriously, VB (and VBA) are perfectly good languages, without most of the faults of C such as uncontrolled use of pointers and IO, string and array operations that can write beyond the end of buffers - though of course it has new faults of its own, plus a few nasties inherited from its earliest days that no sane programmer uses any more.

    It is quite easy for a competent programmer to write clear, readable and even efficient code in VB. I think the reason people see so much bad VB is that it (or rather VBA) is the first language non-programmers try when they're trying to do something in Excel and get told "just write a macro". After which they think they are programmers.

    Self-taught programmers are like self-taught drivers: even when the resulting crashes are spectacular, they will be quite sure that it's not their fault :-)

    For those with poor memories or who suffer from insufficient age, read it at http://www.fortranlib.com/gotoless.htm and weep...

  • Paul (unregistered)

    Maybe they came from assembly language programming that doesn't have if/then/else constructs. E.g.

      test ax,ax
  jz skipit
  add bx, 14h
  jmp short continueon
skipit:
  add cx, 24h
continueon:
  mov dx, 40h
    etc.
  • Ben (unregistered)

    Programmer who uses a goto construts must burn in Hell.

    Not necessarily. If you don't have exceptions available then goto is a perfectly acceptable way of handling errors:

      err = some_function();
  if (err) goto handle_error;
  some_other_function();
  return 0;
handle_error:
 /* handle error */
  return err;

    is nicer IMO than:

      err = 0;
  err = some_function();
  if (!err)
    some_other_function();
  return err;
  • TSK (unregistered)

    Addendum: The code was formatted; the forum software has deleted the whitespace.

  • (cs) in reply to ewan
    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 you can't find a better way to do it, you probably shouldn't be doing it at all. It's not 'bad code' because of a style issue, or some type of fad. It's bad because it introduces more errors. That kind of programming might seem like a good idea but it isn't. There is always a better way of doing it which is less error prone. What justifies it is the cost of hiring someone later on to go in, figure out what happened and fix it. That's usually much more expensive.

  • BF (unregistered) in reply to musigenesis
    musigenesis:
    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

    Both are true. The main thing about VB is that it has fewer "barriers to entry" than most other languages, meaning that it is easier to start using the language if you have no programming experience. This basic aspect of the language meant that a lot more people started using it in the 90s (hence VB code's ubiquity), and a lot more people used it badly (hence the high level of VB code's crapocity).

    crapocity? I love the new vocabulary I pick up on this site </smiles>

  • Jon (unregistered) in reply to mrprogguy
    mrprogguy:
    I'm still waiting for someone to explain this construct (found in K&R, even):

    if(testFailed) return A; else return B;

    I reaaally don't understand how protecting a return with an else is useful.

    It's explicit conditioning for legibility. We know that if the 'if(testFailed)' is false that 'return B;' will be exercised, but the 'else' makes it more easily read.

    CT: pirates... aaaarrrrg

  • Dwayne (unregistered) in reply to ewan
    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.

  • hmmmm... (unregistered) in reply to ewan
    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.

    Stop using computers, please.

  • BF (unregistered) in reply to 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.

  • Ben (unregistered) in reply to mrprogguy
    mrprogguy:
    I'm still waiting for someone to explain this construct (found in K&R, even):

    if(testFailed) return A; else return B;

    I reaaally don't understand how protecting a return with an else is useful.

    I tend to do that because it makes the code structure more obvious, and if someone ever changes the code in the first block (return A) so that it doesn't return, it avoids a potential bug.

  • devious (unregistered)

    Here's a nice example from Microsoft Look at the examples for great VB.Net and C# versions of a goto within an IF within a switch/select... http://samples.gotdotnet.com/quickstart/howto/doc/Xml%5CMultipleXmlReader.aspx

    (To see the C# version, goto (ha!) http://samples.gotdotnet.com/quickstart/howto/ and use the dropdown for language)

  • BF (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.

    Erm, not so sure about that...

    Customer: I'd like a Big Mac (tm) Putz: Do you want fries with that? Customer: No thanks Putz: gosub processOrder '... ' sub: processOrder process burger part of order goto fries ;; no fries

  • Alkari (unregistered)

    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...

  • (cs)
    people continue to prove on a daily basis that simplicity of syntax offers no protection against screw-ups:
    I would argue that the simplicity of the syntax is the reason we see so many screw ups within Visual Basic, ASP, and Coldfusion.

    Because everything seems so "familiar" and semantic, people feel they know what this or that is for, and don't bother to actually learn the language.

    So we get a bunch of idiot programmers with two years experience programming when all they've been making is stuff like that.

    Languages like Java, PHP, C, or Perl tend to scare away the novices. Try-catch blocks? What are these squiggly parenthesis? What the hell is a "float"? Why are there so many exclamation points? What-masking? So you either get moderate code, or those who do try to program in it shortly prove that they shouldn't be.

    This is why I recommend that all HR departments request code examples from applicants, then have the development department looking over it. It's easy to see that the development environment I have doesn't do such a thing.

  • Alky (unregistered)

    This fact should be pounded into all VB programmers' heads. Don't use goto. Just don't. Hell, avoid On error goto as much as you can. If you must use it, mimic a try block like so:

        'TRY { (note this line is a comment!)
        on error goto catch_x
        '...
        '...
        '... code
        '...
    '} CATCH {
catch_x:if err.number then
            '...
            '... catch code
            '...
            '...
            err.clear
        end if
    '} END TRY
  • (cs) 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...

    Is "Alkari" code name for Lucifer because you must be the devil!

  • (cs) in reply to mav
    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.

  • (cs) in reply to !goto
    !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. Of course, there isn't all that much need to program assembly anymore...

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

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article