Top 10 Scary Qt Mistakes

Inspired by Halloween, I'd like to present a list of ten "scary" mistakes using Qt. Based on the wide experience of ICS with Qt consulting projects, I have provided a list of errors that can doom any project.

1. Waiting too long to test on hardware

One of Qt's strengths is its cross-platform support and often when developing for embedded platforms it means that you can start development on a desktop system and not need to wait until your embedded hardware is ready. However, it is important to test your code as soon as possible on the embedded hardware, either the real hardware platform or something similar, like an off-the-shelf development board or reference design. You will want to get Qt up and running as soon as possible so you run some basic benchmarks of performance and resource usage, and then run early versions of your application, even if it is incomplete. If you fail to do this, you run the risk of your application running too slowly, or being plagued by missing or unstable drivers for critical hardware like video, touchscreen and sound.

Finding out that your embedded platform is not suitable late in the project can be a costly mistake, one that can potentially set you back months in your product schedule. It is also important to continue running the software on the embedded platform to avoid regressions as the application is developed.

2. Using underpowered embedded hardware

Qt is quite efficient, given that it is based on the compiled language C++, but it is a large toolkit due to its breadth of functionality. Modern embedded applications can demand a lot in terms of graphics, animation, effects and multi-touch input. Some Qt components, like QtWebKit and QtWebEngine, are very large and resource intensive. QML introduces the overhead of a full JavaScript engine and a just-in-time QML compiler. Your embedded platform needs adequate resources, including CPU, GPU, RAM and file system storage. While hardware costs continue to come down, the expectations of performance are going up and there is increased pressure to reduce hardware costs. Make sure that your hardware is adequate for the needs of your application, with some room for growth in the future.

Sometimes you have an installed base of hardware and don't have the luxury of being able to update it. A worst-case scenario that we have encountered at ICS is when there is a requirement to take an old hardware platform that has limited memory, slow CPU, and no OpenGL support and update with a new Qt and QML-based application. While it can be doable, you need to factor in significant time to optimize the application and set reasonable expectations for features like startup time, animation and responsiveness.

3. Reinventing the wheel

Qt offers a wide range of functionality. There are also more than one hundred third-party libraries and add-ons available for it. Before you implement new functionality yourself, read the Qt documentation and look for suitable third party code. What you need might already exist, saving you significant development time and effort. You should also keep up to date on the Qt roadmap. What you need might be coming in a future release and be available in some form now or in time to use on your project. That said, whenever using third-party code make sure  you carefully review the licensing details. Often it is not licensed the same as Qt and could impose unacceptable restrictions or conflict with your organization's policies.

4. Not investing in training and allowing adequate time for learning Qt

Have you ever heard of the Dunning–Kruger effect? At ICS, we regularly give Qt training classes, typically one week in length. Newcomers to Qt often get excited, for good reason, about Qt's well-designed APIs, elegant signals and slots and simple QML language. However, while one week of training is a good start, it is not enough to become an expert. Qt (including QML) has some complex areas and gotchas that aren't immediately obvious. Take time to read the documentation and look at example applications. Follow the mailing lists, read the forums and blog posts. Don't use Qt for the first time on a "bet the company" project; pick a low risk one to start. Also be sure to secure a solid background on modern C++, such as C++11 and C++14 features.

5. Not using Qt as it was meant to be used

One of the greatest benefits of Qt is high developer productivity, when you use it the way it was meant to be used. At ICS, we have seen customers use Qt in strange ways that cancel out many of the benefits. A few examples: Don't write a wrapper around Qt thinking you might port it to another framework someday. Don't write thousands of lines of JavaScript code inside QML. Don't write your own container classes unless you have special requirements. Remember, Qt is much more than just a GUI toolkit, so in general you should use it throughout your application. However, it is okay to have non-Qt, even C language, portions of your code. While you will get conflicting advice, it is generally okay to use libraries like BOOST if you choose to.

6. Not giving back to the Qt community

Qt is a community project where anyone can contribute. Doing so will help Qt get even better. Report bugs that you find, review bugs and patches, or even fix bugs (if not in Qt itself, you can correct errors in the documentation or code examples). Help test new Qt modules, and try out Alpha, Beta, and RC releases and new modules that are in Tech Preview status. Consider giving a presentation at the Qt World Summit. A 10-minute lightning talk is not a large commitment.

7. Ignoring portability

You might think that your code will never run on other platforms, but that often changes. Code tends to live for a long time. A couple of years from now someone in Marketing may want the application to run on Linux, Mac OS or Android. Using Qt rather than native APIs is often easier. Build and test your code on other platforms and with other compilers; you may find subtle errors or bugs that are in the code today. Even on the same platform, you may run into 32 versus 64-bit issues that testing on a different platform can uncover. At the architecture level, you may want to think about separating the presentation from the business logic to make it easier (or at least possible) to move the code, say, from the desktop to a touchscreen interface (which might mean moving from widgets to QML).

8. Not choosing a suitable Qt version

As a developer, we tend to want to use the latest and greatest versions of software. However, the latest alpha release of Qt might not be what you want to ship for production code. While it is not recommended for new development, many people are still using Qt version 4, for example. Strike a balance between keeping reasonably up to date, and not necessarily using the latest release. Testing, or at least building, your code with new releases is a good idea. A general rule of thumb is to avoid dot zero releases of Qt or other third party software.

9. Not keeping your Qt and C++ skills up to date

Some of us may have used Qt and C++ for years, but it is important to keep your skills updated. Are you up on the latest features of Qt Quick 2? Are you familiar with the features in the C++11 and C++14 standards?

Even if you aren't using the latest version, you should monitor development of Qt and be aware, for example, of new modules coming, and what old modules are being deprecated in the future. Follow the development of new C++ standards. Take advanced Qt or C++ courses or attend webinars (these are often free). Go to the annual Qt developer conference or roadshow events.

When you are up to date with your Qt knowledge, one way to be recognized for your effort is to get official Qt certification.

10. Not following Qt best practices

Qt has a number of best practices that will improve the quality of your code and make it easier for others who have to work with it. Follow the coding and style conventions C++ and QML (either the ones published by the Qt project or whatever standard your organization might have). Follow the mailing lists and learn the common problems and questions that other developers have. Use an integrated development environment (IDE) like Qt Creator. The specific IDE is not important, but knowing it well can greatly improve your productivity. Following some of the best practices in programming methodologies, such as having a testing process, performing peer code reviews (tools like Gerrit can make this painless and distributed) and implementing a CI system for automated builds.

The KDE project has a document on common programming mistakes specific to KDE, many of which are relevant to Qt. A recently announced initiative is the C++ Core Guidelines from which you can benefit from the knowledge of developers like C++ creator Bjarne Stroustrup.

Summary

I hope this list of "scary" mistakes will help you avoid problems that we often see our customers run into. Now if you'll excuse me, I have to get back to working on my current problem. For some reason I am getting zombie processes when using QProcess and it only started happening today...