Using Visual Studio Code for Writing Qt Applications

27.11.2019 Matthias Kalle Dalheimer 17 comments

Software developers like tools, and in particular tools that make them more productive. So in this blog post, I am going to share with you some of the experiences some of us here at KDAB have had using Visual Studio Code for Qt development.

Motivation of using Visual Studio Code instead of Qt Creator

The first question you want to ask is probably, “Why use another editor or IDE at all if we have Qt Creator, which is a perfectly good and, in particular, Qt-specific IDE, ready at our disposal?” And, of course, that’s a very valid question to ask.

For me, the main reason is that Visual Studio Code simply does some things better than Qt Creator – and other things worse, which I’ll discuss later. Also, I am doing a lot of my development on macOS, and Qt Creator does not always have the same level of stability there as it does on Linux and Windows. I am not advocating to ditch Qt Creator altogether. My current work setup uses both in parallel.

I have configured both to auto-save and auto-reload so that I can switch seamlessly between the two. Some things I do in Qt Creator, while others I do in Visual Studio Code. When I move focus, my changes are already there (or I just need to hit the “Yes to All” button in the reload confirmation dialog) and I am getting the best of both worlds.

Visual Studio… Code?

Before I go into greater detail, I’d like to explain a bit about Visual Studio Code. Many of you are most likely familiar with Microsoft Visual Studio. If not, here’s a quick summary.

Microsoft Visual Studio is Microsoft’s big and comprehensive IDE/compiler/debugger package for C# and C++ development that has been around for many years and is available for Windows and macOS (but not for Linux). And, here’s the confusing bit: Visual Studio Code has very little to do with Microsoft Visual Studio. (Though, I would guess that they use a lot of common code under the hood.)

Visual Studio Code is an offering of its own, open source, not commercialized (for the time being at least), and based on Electron. It doesn’t use the Atom editor component though, like many other development tools built with Electron. Instead, it uses a separate editor component that is also used in Microsoft’s Azure DevOps product. This is not something you need to worry about, or even know, when working with Code, of course.

Visual Studio Code (or Code, for short) can be downloaded free of charge from here.

Visual Studio Code Extensions

One of the things you’ll quickly discover with Code is the staggering amount of extensions available. Many times, when you ask yourself, “Can Code do X?”, the answer will be: “Out-of-the-box, no, with an extension, yes, just fine.”

The sheer amount of available extensions (all of them free as in beer, though some of their developers ask for a small and usually well-deserved contribution) can sometimes be confusing, especially when there are several that seem to serve the same purpose. There’s a rating system though.  Whenever I was uncertain, I quickly tried several. Many of these serve very small and well-defined purposes so you can quickly find out whether a specific extension is what you need.  All extensions can be installed without leaving Code.

In fact, for my particular purpose, Qt/C++ development using Code is not supported out of the box. Code’s heritage is ‘webby’, JavaScript-related languages such as TypeScript. Installing the C/C++ extension (developed by Microsoft themselves) gives you most of what you want, though, at least in the C++ department.

VS Code or Qt Creator?

So, this being said, what are the pros and cons of using Code over Qt Creator?

First of all, at this time, Code has no knowledge of Qt itself. It doesn’t know about signals and slots, .ui or .ts files, or QML or Qt Designer. And that alone is, of course, reason enough not to switch to Code entirely. Anything that is very Qt-specific is better done in Qt Creator. It is entirely conceivable that somebody at some point in the future will write a Qt extension for Code (who knows, maybe even a KDABian?), but at this point, to the best of my knowledge, such an extension doesn’t exist.

So, if Code doesn’t know about Qt or QML, why even use it for Qt-based development? Well, even in Qt-based projects, not every task in a programmer’s life is Qt-specific. As an example, Code’s global search-and-replace functionality is vastly superior to Qt Creator’s.

Here at KDAB, we often work with very large customer code bases, often old, often without access to the original developers, so finding our way around these is key to our work. Code lets you search for symbols in a very fine-tuned way, and also lets you replace with a lot of control (by folder, by file, by individual change, with full syntax-colored diff for every potential change etc). I often find myself switching from Creator to Code just to do a search (and sometimes a replace), and then switching back.

Managing Visual Studio Code projects

A bit of a difference in how the two work is that Qt Creator, like most IDEs, is project-based. You open one (or more) projects, and it’ll load information about all files in the project, as defined in the build file (QMake .pro file or CMake CMakeLists.txt). The advantage of this is, of course, that you can’t miss anything since everything that is built is also opened and read by Qt Creator.

Visual Studio Code, on the other hand, works folder-based. You open one folder at a time (and can combine several folders into so-called “workspaces” that are opened together), so you have a finer-grained control.  However, it is easy to miss files that are in a separate folder. As previously mentioned, the code bases we often deal with at KDAB are very large (several million LOCs are not unusual), and sometimes it’s just more convenient to only open a subset of them, since opening several hundred files can slow down the best of IDEs.

Code Completion

What about code completion? Intelligent code completion has made the lives of developers so much easier, so it’s one of the most important features in any IDE. In fact, I would say it’s a tie here. Microsoft has “donated” the reputable Intellisense code completion from the big Visual Studio product to Code, but Qt Creator’s code completion is also rather nice and convenient, and they both work similarly enough to each other that it’s not too confusing to switch between the two frequently. Setting up Intellisense can be a bit of a hassle sometimes, especially when using CLang, but there is good documentation to help with that.

VSC Integration

Another advantage of Code is its very extensive support for version control systems (which these days, let’s face it, essentially means git). Qt Creator does have comprehensive git support, but I don’t find it very accessible. In particular, it is not very integrated with the actual act of writing code.

With Code, I can get small annotations about who changed a line of code and when, in a subdued color. These are easy to ignore when you don’t need them, but available right away when you do; this is much more efficient that running git log or git blame separately (this particular feature comes by way of the GitLens extension). Even other developer tools are nicely integrated; for example, if your organization is using Atlassian’s Jira issue tracking system, as we do here at KDAB, there is a convenient and comprehensive extension for that.

CMake

Finally, a few words about CMake. With the recent decision to make CMake the default build tool for Qt-based projects, this will likely change, but at this time, CMake is not really a first-class citizen in Qt Creator, which was built very much around QMake.

You certainly can use Qt Creator’s nice scaffolding for new projects and tell it to use CMake, but if you add new files or classes, you’ll need to add them manually to your CMakeLists.txt Code by way of the CMake extension, which gives you a lot more support here, at least for the time being. It remains to be seen how much CMake support there’ll be in Qt Creator once Qt 6 is released.

Summary

In summary, we would advise Qt developers who care about their productivity to give Visual Studio Code a try. It won’t replace Qt Creator in the foreseeable future (maybe never), but it certainly is yet another tool in the shed that helps you write more and better code in less time.

If you’re interested in more, you may want to read our two part article on getting Visual Studio Code configured for Qt development.

Editorial note (28 Nov 2019)

A previous version of this post had some incorrect information regarding the support for multiple programming languages in VS Code and Qt Creator. We have removed such incorrect information to avoid spreading it further. We apologize for the mistake.