Should you use GoTo?

It is written in the Xojo docs that you should not use GoTo. I am in a situation where I feel the need to use a goto statement to proceed through some code.

Here is the simplified version of my code to make the problem easier to understand and faster to interpret for others.

  check:
call IncrementedNamingMachanism()
  
  //Check if this new name is unique from any other
  dim uniqueName as boolean = true
  for each obj as namedObject in namedObjects
    if obj = me then continue //skip if its came across itself in the loop
    if obj.name = name then //came across object with the same name
      uniqueName = false //found that it is in fact not unique from any other name
    end if
  next
  if uniqueName = false then  //if found not be unique through the loop
    name = name+"1" //add a "1" at the end
    goto check //recheck if it is unique and if it found to be unique then it will stop cycling through this naming machanism
  end if

How can I change this so I do not need to use the goto function or is this one of the cases where it is fine to use the goto function?

Thanks

I would suggest NEVER using a goto statement under any conditions. It is an old style programming structure that is going to make your code more difficult to maintain down the road. Been there 30+ years ago and haven’t used a goto in forever.

I’d change your code to something more along these lines.

While Not uniqueName
call IncrementedNamingMachanism()

//Check if this new name is unique from any other
dim uniqueName as boolean = true
for each obj as namedObject in namedObjects
if obj = me then continue //skip if its came across itself in the loop
if obj.name = name then //came across object with the same name
uniqueName = false //found that it is in fact not unique from any other name
end if
next
if Not uniqueName then //if found not be unique through the loop
name = name+“1” //add a “1” at the end
end if
Wend

Why don’t you just keep it all in a loop?

It looks like you are just testing 1 namedObject so I’d use a For Next Loop

Dim objCount as Integer = Ubound(namedObjects) - 1

For Count As Integer = 0 to objCount

If obj.name = name then
obj.name = obj.name + “1”
Count = -1
End If
Next Count

or something like that.

[quote=56663:@Michael Bierly]I would suggest NEVER using a goto statement under any conditions. It is an old style programming structure that is going to make your code more difficult to maintain down the road. Been there 30+ years ago and haven’t used a goto in forever.

I’d change your code to something more along these lines.

While Not uniqueName
call IncrementedNamingMachanism()

//Check if this new name is unique from any other
dim uniqueName as boolean = true
for each obj as namedObject in namedObjects
if obj = me then continue //skip if its came across itself in the loop
if obj.name = name then //came across object with the same name
uniqueName = false //found that it is in fact not unique from any other name
end if
next
if Not uniqueName then //if found not be unique through the loop
name = name+“1” //add a “1” at the end
end if
Wend[/quote]
Thankyou. I have managed to think in a more structured manner and it did not take too much doing. I thought of this method but I obviously was not implementing it correctly, thankyou.

[quote=56665:@Jym Morton]Why don’t you just keep it all in a loop?

It looks like you are just testing 1 namedObject so I’d use a For Next Loop

Dim objCount as Integer = Ubound(namedObjects) - 1

For Count As Integer = 0 to objCount

If obj.name = name then
obj.name = obj.name + “1”
Count = -1
End If
Next Count

or something like that.[/quote]
I loop over twice to guarantee that the name of the object will not be the same as any other objects. It only uses numbers if there is an object with the same name. Thanks

Goto should be the option of last resort. I would strongly suggest refactoring your code first to see if you can avoid its use.

There are some instances I’ve found over the years where they make a bit of sense but it’s been just a handful in 13+ years of REALbasic/Xojo coding. If I had had the time I probably could have refactored the code.

[quote=56669:@Bob Keeney]Goto should be the option of last resort. I would strongly suggest refactoring your code first to see if you can avoid its use.

There are some instances I’ve found over the years where they make a bit of sense but it’s been just a handful in 13+ years of REALbasic/Xojo coding. If I had had the time I probably could have refactored the code.[/quote]
I

[quote=56669:@Bob Keeney]Goto should be the option of last resort. I would strongly suggest refactoring your code first to see if you can avoid its use.

There are some instances I’ve found over the years where they make a bit of sense but it’s been just a handful in 13+ years of REALbasic/Xojo coding. If I had had the time I probably could have refactored the code.[/quote]
I would not be suprised if Xojo decided to remove this function from Xojo for the benifit of Xojo users. I have found two goto statements with someone else’s code.

I’d be surprised.

I’ve used GOTO in exactly one situation: a text parser. It turned out to be faster than a structured code approach, and I was trying to squeeze performance out of the system. I don’t otherwise find myself tempted to use GOTO, and I would advise anyone considering it to keep asking themselves, “Is there a better way to do this?” until they can answer “yes”. :slight_smile:

Yeah, I get it.

If the name is the same then you Add the number “1” to it and start the loop over to make sure none of the obj’s prior to where you are at in the loop have the same name.

if obj.name = name then
obj.name = obj.name + “1”
Count = -1
End if
Next

I’ve done very fast parsers in Xojo and not needed to use GoTo. In addition to it meaning less structured code, there are cases where it can cause memory leaks.

Perhaps I should send you my code for inspection.l :slight_smile:

I’m pretty confident it was the right thing to do in my specific circumstance. Thousands of lines of text, each one needs to be inspected, it’s a lot faster to use IF…THEN instead of RegEx, so once a match is made we skip all the rest of the tests.

Yeah, but why do you need a goto? I’m guessing you’re looping through the lines of TEXT, just end the loop?

There are many instances such as Thousands of If/Then/End If tests. Once the conditional if-then has been found skip to the next part of the code. Otherwise, your code is slowed down slightly such as in the instance of the PHP interpreteter I wrote using Real Studio 2 years ago (PHP clone in Realbasic)… Although the GOTO was not necessary since there were if-thens, I found that without GOTO it interpreted PHP code in about 500MS…with GOTO only 20MS…

You be the judge. If it works for you, use it. I believe un-godly amounts of if-thens benefit from GOTO once the conditions have been met.

Another instance GOTO is handy is in “Artificial Intelligence” algorithms. Although you can avoid goto, it saves repetitious code and un-godly complexities.

Matthew, that’s exactly the scenario I have. It was more important for the code to be fast than for it to be structured, and I kept the code blocks very clean so it is still easy to understand what’s going on.

However, this was a fairly unusual scenario, and I haven’t used it since. Generally, performance is less of an issue and code structure takes precedence.

Is that so? I have developed various AI applications (in LISP) and never found a use for goto. And there was no repetitious or unduly complex code because of that.

Goto is a controversy based on quasi-religious beliefs :wink:

At work we use a lot of assembly language, we use the Jmp instruction which is essential and would be equivalent to
the goto statement.

But in high level languages it is forbidden to use it since it could easily cause crashes from misuse.

If used properly, I see no reason not to use it. I believe most basic languages allow goto and gosub statement.