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.