At XDC 2019 my session was titled Xojo Design Mistakes (the alternate but way longer title was ‘Thankfully time travel doesn’t exist or my future self might travel back and murder my younger self for the stupid coding mistakes I’ve made’). These are things that I’ve discovered over the years, both in my own projects and in other peoples projects that are just plain wrong or less than ideal. This will be an on-going series since I had well over 50 slides and left about 150 out. So when I get bored I’ll bring these topics up.
Don’t use GoTo – ever. GoTo is a holdover from the old BASIC days where code was unstructured and you needed to manage flow-of-control. Old BASIC programs used a ton of GoTo statements because, well, you just had to. It was the only way to get anything done. Xojo uses a modern BASIC syntax but it’s fully object-oriented code and still has GoTo as a reserved keyword and it still functions.
Xojo has many ways of doing flow control. There are multiple ways of doing loops with While’s, Do-Loop’s, For-Next’s, and we control those loops with keywords such as Continue, Exit, Return. Since we have methods and functions too we can exit those by calling Return at any point in the method and the code resumes execution at that point. GoTo just isn’t needed any more.
And yet GoTo still exists. I recently ran across this code in a project we’re updating for a client.
As you can see we are in a fairly typical For-Next loop iterating through a ListBox. The first line into the loop we check if we’re closing the window and if we are we call GoTo bale which takes us to where bail: is. Bail is at the bottom of the method and we’re doing nothing afterwards (the last two lines are Exception handling in this method and aren’t called).
This is such a poor example of Xojo coding. We can use Exit to accomplish the same thing since Exit will immediately exit the loop and since there would be nothing after the loop it would simply leave the method entirely by simply calling Return. There’s no penalty for using either Exit or Return.
Honestly, I have no idea why the original developer did this. I think they came from VB6 where code like this was pretty common, but even in that language there were much better ways to do the same thing. So I will call this lazy coding because the developer didn’t use the best way in Xojo.
Using GoTo like this is potentially risky too. Feedback case 24710 shows that using GoTo may cause a memory leak because the compiler may skip cleanup code. I think the above code is safe but I could see if we loaded oNote before the GoTo exiting the loop it would be dangerous. But even still, if GoTo is outdated, not recommend, and dangerous on top of all that why use it? I can think of at least three ways to make this code safer and better.
At the end of the day, If you’re using GoTo – don’t. Refactor your code so it makes use of the modern Xojo calls. It’s safer and the right way to code in Xojo. Your future self will thank you.
(267)
Thank you for pointing this out. It was already bad coding attitude in Visual Basic 6, and so believe “Goto’s” are the main and sole reason why elder coders do hate Basic for good and obvious reasons.
I understand and I do embrace that xojo is still supporting in 2019 this legacy but really no one should still use it 😂
No serious programming language should support legacy like GOTO . I would encourage Xojo to throw this out.
Like C or C++ does ? 😛
https://en.cppreference.com/w/cpp/language/goto
Or “labelled statements” in swift
https://docs.swift.org/swift-book/LanguageGuide/ControlFlow.html
Ok Norman, you’re right. But still I don’t like GOTO . 🙂
C and C++ have it
I doubt anyone would say they’re not serious languages
Several others have various more structured forms of goto called “labelled statements” (Swift, Java and Javascript)
The only one of the top 5 languages on TIOBE’s list that doesn’t have any form of goto that I know of is Python
I’ve found that goto is usually the last tool I reach for in the toolbox, but it does have its uses and can lead to cleaner code under some circumstances (such as when implementing some low-level intercommunication protocols). But I definitely agree it should not be one of the first tools you reach for when trying to solve a problem!
However, it’s rather disappointing when you cannot trust a programming language primitive because it introduces things like memory leaks. 🙁
sadly that leak has existed for some time
joe and I found it in some IDE work I was doing where I noticed there was a weird leak 🙁
Formatted Text Control uses also GOTO.
Those need to get expunged in the next version.
If you see a label you know there may be a goto, no such visual clue alerts you the the possibility of a return lurking somewhere unless you see it. So it’s twice as hard to see a return
I think that the possibility of random returns in code can cause just as many problems.
What if someone plonks a return in a try block with a commit at the end of it and a rollback in the catch.
If whoever wrote that code uses gotos like that consistently I don’t see much wrong with it.
Except for the bit that breaking out of a loop using a GoTo could cause a memory leak. *This* example appears to be fine but it’s also a very simple example with much easier (and sanctioned) ways to accomplish the same thing.
To me this is like the old Accessing UI via a thread. Xojo said don’t do because it will generate some random crashes. But we all did anyway until they disallowed and we all bitched about it.
I think it’s just as simple to say Don’t use GoTo ever. I’ve listed the why’s but if you still feel like gambling with your application feel free to use it.
This is why I refuse to use
If something then return
and prefer
if something then
return
end if
they’re easier to spot and easier to debug since you can put a break point ON the return
And I would use them and return from any point that a failure is detected that means the method should end rather than nest things deeply in “if then else”