Code doesn’t care whether you are new to programming or an old pro, a citizen developer or the head of engineering, some missteps can catch any of us. Read on to learn some of the most common programming pitfalls and how to avoid them.

Ignoring Encoding

When working with Strings that come from (or are sent) outside your app, you always need to consider the encoding of the text. These days, UTF8 is the most common encoding for text and probably the one you should use most of the time. But if you’re getting text from a database or a web service or just another file that you don’t control, then you’ll want to use the DefineEncoding method to set the correct encoding of the incoming text or use ConvertEncoding to cover the encoding to something you’d rather be using, such as UTF8.

Avoiding Exception Handling

Some classes raise exceptions when something unexpected happens. If your code ignores these exceptions then this causes your app to display an error message to the user which forces them to quit the app. That’s not the best experience.

Use Try…Catch code to ensure exceptions are caught and dealt with appropriately and gracefully.

As an example, if you call XMLDocument.LoadXML and supply invalid XML, then an XMLException is raised. By catching this exception you can display a message to the user telling them the XML file they selected is invalid and asking them to choose another.

Skipping Database Error Checking

Whenever you run a database command it is possible that there was a database error that happened. Some languages might raise an exception for this, but others may require you to check for an error.

This can really help with catching subtle problems, such as a typo in a SELECT statement.

Ignoring Memory Leaks

A memory leak in your app is when it keeps reserving memory but never gives it back. Oftentimes this is not noticeable as the increased memory usage is minimal and does not typically affect 64-bit apps. In addition the memory is released when your app quits. But if you have a significant memory leak you should look into figuring out how to eliminate it.

You can determine if your app has a memory leak by checking (using the OS Task Manager or Activity Monitor) if its memory usage increases significantly as the app is used even while you are closing windows or documents that are no longer used.

It is possible you have some objects that are never going Nil and thus not releasing their memory. Normally you don’t have to worry about setting objects to Nil manually as the memory manager (garbage collection and automatic reference counting are common) cleans up things when they're no longer used. But there is a situation, called a circular reference, that can lead to objects not being set to Nil.

A circular reference means that ObjectA refers to ObjectB and ObjectB refers to ObjectA. Since neither ever has its reference count get to zero, then they cannot be released from memory.

You can either manually set things to Nil to ensure that memory is released or you can make use of the WeakRef class to help manage it.

Fuzzy Graphics in HiDPI

If your language supports it, take advantage of HiDPI (retina) displays by including larger size images. If you only include a single image it might be used at 1x size and will get scaled and look fuzzy or blurry on HiDPI screens. Instead make sure you have multiple image sizes in your project, so the better image can be used on HiDPI screens.

Not Updating to 64-bit

For macOS, you should definitely be updating your projects so they build 64-bit apps. It’s likely that the version of macOS that is released later this year will no longer support 32-bit apps at all and you’ll want to be prepared. For some tools this is trivial (in Xojo you just change a drop-down menu selection).

It’s less of a rush on Windows as 64-bit versions of Windows still fully support 32-bit apps. However, on a 64-bit version of Windows, which are becoming increasingly common, you will get better overall performance as the OS does not have to load 32-bit compatibility layers which use up memory and CPU.

On Linux, 64-bit distributions are becoming more and more common and many do not include any built-in support for 32-bit apps. So you’ll want to be able to distribute a 64-bit app if at all possible.

Cut and Paste Coding

Don't blindly use code snippets that you find in your Google, Stack Overflow or dev.to searches. Take the time to understand what the code does. Use it as a learning experience. Because if that code ever breaks in the future (for whatever reason) and you never knew how it worked, how can you expect to be able to fix it in a timely manner?

Not Checking the Docs

Everyone likes to complain about docs, but I find that far too often people don't even bother checking them before they complain! Perhaps the docs don't have the exact block of code that you want, but you can't expect the docs to write all your code for you. Use the docs to understand what something does, write small programs to test out commands and your assumptions so that you can code what you need.

I also recommend that people try reading the docs ahead of time to get an understanding of what is available to you, rather than just randomly searching for things you might need.

I think I'll stop there as I could probably go on for a while. What are some pitfalls that you've seen?