PSPDFKit has a large C++ codebase. Our developers write, debug, and commit C++ code to the PSPDFKit repository every day, and we use a variety of IDEs and text editors in the process.
The PSPDFKit codebase is not tied to any particular IDE, which means our developers are free to use their IDE or text editor of choice. Because of this freedom, and also because we develop C++ for many different platforms — including Linux, macOS, and Windows — the number of tools we use to write C++ code is significant.
In this blog post, I’ll summarize what we consider to be the most interesting C++ IDEs and text editors as of 2020. I’ll also share their pros and cons based on the experience we have using them.
The first big group of development tools is that of integrated development environments, or IDEs. These are programs that include many different things required during development, such as a text editor, an integrated debugger, and different code assistance features that make browsing a big codebase an easier task. Within this group of tools, we want to highlight JetBrain’s CLion (multiplatform), Xcode (macOS), and Visual Studio (Windows).
CLion is a C++ IDE developed by JetBrains. It’s primarily written in Java, and it’s based on JetBrains’s own IDE infrastructure that is shared among other popular Java products, including IntelliJ IDEA, PyCharm, and WebStorm. CLion’s support for CMake projects is very good, so you usually don’t need to spend a lot of time getting a CMake-based project working.
CLion provides many different code assistance features that give users the ability to complete code, go to the definition of any symbol, search for code references, and navigate class hierarchies. These features are important in a large C++ codebase like the PSPDFKit one, because developers are usually not completely familiar with the part of code they are working on, and being able to navigate the code in a variety of ways helps them understand it more quickly.
CLion also integrates well with some linting tools we use, including clang-tidy and clang-format. To ensure this works seamlessly, we configure CLion to always use a specific version of clang-tidy and clang-format and not what it comes bundled with, because it’s important that every developer on the team lints and formats the codebase in the same way.
However, one of the problems we’ve encountered with CLion pertains to performance: The time it takes to completely index an entire project can be very long, especially if the code has a high number of C++ templates. This is because parsing C++ templates is a complex problem. Additionally, in some cases, the IDE may not be very responsive while indexing.
That said, we’ve found two things that help mitigate this issue: increasing the amount of heap memory dedicated to CLion’s Java VM, and trying to only import the subproject that is actively being worked on. This page on performance tuning provides some helpful tips. JetBrains continually invests a lot of resources into improving CLion’s performance, so it’s important to always check for the latest version.
Xcode is a C++ IDE developed by Apple. We use Xcode because it’s tightly integrated with other languages we use in our PSPDFKit for iOS product: Objective C, Objective C++, and Swift. The integrated debugger (LLDB) is also easy to set up and use.
Here’s an article where we describe how we extended LLDB to work better for our C++ codebase. We don’t think indexing a large-scale C++ project in Xcode is particularly slow, and the IDE remains functional while the project is indexing. We have spent some time improving how Xcode indexes our project because we think it’s good for developer productivity. Meanwhile, in this article, we describe how Xcode indexing works and how you can make it work better for your project.
The main disadvantage we see in Xcode compared to other IDEs is that the code assistance features are not as powerful. For example, Xcode provides good support for jumping to a definition and calling references, but the only refactoring that is supported out of the box is symbol renaming.
Another downside to Xcode is it’s not as extensible as other IDEs, and that complicates the integration of code formatting and linting tools. We have been able to create some extensions for linting our documentation and formatting our code that we share with the iOS team, but overall, we think the set of things in Xcode that can officially be extended is still limited.
Visual Studio also supports a rich set of extensions. One example of this is ReSharper, which improves the C# code assistance provided by Visual Studio with interesting refactorings like the ability to extract interfaces and move up member functions. For C++, we especially like Visual Studio’s build analysis tools, which help us discover and fix subtle problems that slow down our builds, such as an excessive number of header
Although Visual Studio’s support for C++ is good, we usually need to complement it with third-party extensions like Visual Assist in order to match other IDEs. Additionally, although we think Visual Studio’s integrated debugger is powerful and easy to use, we’ve had some problems when trying to debug multiple languages in the same session. That said, we think no vendor has completely solved the problem of debugging code in multiple programming languages yet.
Some people at PSPDFKit prefer to use a simple text editor to develop in C++. Thanks to the Language Server Protocol (LSP), the line between a text editor and an IDE has been blurred, and many text editors support advanced features such as code completion and name refactoring.
The main text editor that supports LSP is Visual Studio Code, although the protocol is also implemented by less popular text editors like Vim, Sublime Text, Atom, and Emacs. Some benefits we see in using text editors to develop in C++ is that they tend to be faster, they are available for multiple platforms, and they are usually free and open source.
In the next section, I’ll briefly explain how LSP works with C++ (with Visual Studio Code as its “gold standard” implementation).
Visual Studio Code is a powerful text editor created and released by Microsoft in 2015. There are many extensions available for C++ development, including an official extension from Microsoft, the ccls extension, and the clangd extension. These extensions implement LSP, which is a protocol designed by Microsoft to decouple text editors from code assistance features.
Our team prefers the ccls and clangd extensions, as they seem to receive more regular updates and improvements. For example, you can see the range of code assistance features that clangd supports here. For integrated C++ debugging, Visual Studio Code also supports several extensions. We have written a more detailed post about our experience working with Visual Studio Code in the PSPDFKit codebase.
Thanks to LSP, many other text editors have gained “IDE-like” capabilities without being proper IDEs. Neovim has supported LSP natively since this PR, there’s a popular extension for Atom, and Sublime Text also has support for LSP.
The main disadvantage of LSP-based editors is that, even though a lot of code assistance features are supported, things like refactoring are still not as complete as they are in full-featured IDEs. Another disadvantage is that adding LSP support to text editors usually requires a non-trivial amount of configuration.
In this blog post, we explored different IDEs and text editors that can be used to write C++ and shared the pros and cons of using them.
We don’t see a tool that is a clear winner for C++ development. However, we’re pleased to see there’s recently been a lot of innovation regarding C++ tooling, so it’s safe to say it’s the best possible time to develop in C++, as there are more options than ever.
That said, we also have some criticism; for example, we don’t think C++ tooling is at the same level as tooling for other languages is (Java being a prime example). However, we’re always interested in opportunities where PSPDFKit could contribute to help make the C++ ecosystem better.
Our main recommendation is that your organization does not tie projects to any particular text editor or IDE, and that the company fosters a culture of maintaining a set of small project-specific extensions for developers who use a particular IDE. If developers are free to use the environment they are more familiar with, they’ll be happier, they will probably stay longer at your company, and they will ultimately be more productive.