RB Code "Best Practices"

Long time reader and all-around great guy, Bob asked via the Suggestion Box to comment on the best practices for coding in REALbasic. Unfortunately, this is an incredibly difficult thing to really discuss because it's such a huge topic! I'm going to try to keep away from general coding practices such as "always comment your code" and "write your code like a serial killer has to maintain it and they know where you sleep." ;-)

Test early, test often.
Yes, REALbasic is a cross-platform tool that allows you to design your code on one platform and deploy to another. It's also better at it than most other tools I've ever seen. However, that doesn't excuse you (as a developer) from doing work! Quite frequently I hear stories from people who spend months and months developing an application on the Mac, and then the day before they need to release it they run it on Windows and are shocked that their application isn't ready. If you want a professional application on any platform, you have to test early and test often! Platforms behave differently, they look different, their users have different expectations, etc. So don't fall into this trap -- always try your projects on every platform you intend to support, and if you do it from early on, there won't be any nasty surprises waiting for you.

Love your code
Code hates to be neglected, and doing so tends to lead to "bit rot." Don't be afraid to go back and keep "working" code up to date. I know this is a universal truth in computing, but it's especially important in REALbasic. The language is constantly evolving, and what may have been the best way to write something a year ago may now have a much better way to do it today. While it's certainly much easier to take advantage of new technologies when starting a project out, it's still beneficial to improve existing code bases from time to time as well.

Code defensively
Ug... another universal truth. But it stands to be repeated over and over again -- always code defensively! I know it's blindingly easy to skip a nil check, or a bounds check, etc in REALbasic. But those are just bugs waiting to happen. Take it from someone who reads every single automatic report that comes in. ;-) It takes two seconds to add a safety check, and it saves you tons of time in maintenance costs in the long run.

Untruths
Sometimes I come across some pieces of code in bug reports that makes me go "huh?" I like to call these "Untruths" because they're things people think are true, but really aren't. It's impossible to list all of the untruths because coding mistakes are a dime a dozen. But here are some very common mistakes I see:

• GetFolderItem( "" ).Child( "Foobar" ) -- this is entirely unnecessary, since GetFolderItem's parameter is a child file/folder. I think this one came about because there was a code example in the LR showcasing it! Ack!
• Doing the same thing multiple times -- I've seen this one in so many forms. People will set the same object reference to nil multiple times in a row. Or try to delete a file until it no longer exists, etc. Whenever you find yourself doing this sort of thing, take a step back and you'll probably find that you're doing something wrong.
• Allocate and ignore -- this one happens very frequently as well. I'll see people do things like dim foo as new Bar, and then the very next line say foo = SomeRBApiThat ReturnsBar. You're just wasting cycles -- if an RB API returns an object, chances are exceedingly good that it's allocating the object. I used to see this a lot with RecordSet before we protected its Constructor...
• Failing to really understand OOP. I know this could be considered more of a universal thing, but it's especially important in REALbasic. If you are designing a GUI application in REALbasic, there is literally *no way* to escape object oriented programming. So if you don't really understand classes, or events or things like that, you should take it upon yourself to learn. There are good resources that can be found on Amazon, RBLibrary, RBGarage or even in people's blogs. It can take a bit to wrap your head around it at first, but it will do you a world of good to have an understanding of OOP in REALbasic.

Be Constructive!
Ok, this really doesn't count as a coding practice. But I still like to mention it when the opportunity arises. ;-) If you do run into a bug in the product, remember that every person who reads that report is probably very passionate about the product and really wants it to be as stable as possible. So don't say things in your bug report that you wouldn't say to a friend's face. It can be easy to vent your frustrations when you run into bugs, but it doesn't do anyone any good to be spiteful about it (whether in a bug report, or discussing it in public/private).

I am sure I'm missing some best practices -- it's very hard to list them all in one sitting. But these cover some of the most common issues I see people running up against. What would you add to the list?