If you’re a software developer, there’s a decent chance you’ve been embroiled in the debate over integrated development environments (IDEs) versus text editors. Users of IDEs will tell you that they facilitate productivity to a degree that makes them indispensable, whereas users of text editors will tell you that the IDEs are too big and bloated and hide too much of the truth of what’s happening from you. In some cases, depending on the tech stack and personalities involved, this can become a pretty serious debate.
I have no intention whatsoever of wading into the middle of that debate here today. Rather, I’d like to tackle this subject from a slightly different angle. Let’s take at face value that text editors are comparably feature-poor but nimble and that IDEs are comparably feature-rich but laden with abstraction. Framed as a tradeoff, then, it becomes clear that realizing the benefits of one choice is critical for justifying it. To put it more concretely, if you’re going to incur the overhead of an IDE, then it had better be doing you some good.
With this in mind, what should you expect from an IDE? What should it do in order to justify its existence, and what should be a deal breaker if missing? Let’s take a look at what’s reasonable to expect from IDEs.
Building the Software
First up, any IDE worth its salt should be able to build your software with a key press or a mouse click. If you’re used to using text editors, some of them may have this capability available as a plugin, but you may also be in the habit of kicking off a build as a shell script command. You would then look at the output from the build attempt and navigate your way to the offending file if something went wrong. This approach gives you a lot more control over and knowledge of the build but it’s also not the same, fluid abstraction.
An IDE should be able to build the software easily, and it should neatly and concisely show you anything that goes wrong with the build. What’s more, you should be able to navigate with a click from the error to the file and line in question. In fact, the IDE might even supply a suggestion for how to fix the problem. Your IDE should be very knowledgeable about building your software so that you don’t have to leverage this knowledge with each individual build.
A related, absolute must for an IDE is debugging capability. Again, some text editors might be able to assume this capability courtesy of plugins, but part of their lightweight nature is eschewing concerns like this out of the box. With a text editor, you might rely entirely on some combination of the code’s unit test suite, logging, and temporarily inserted print statements to track down runtime issues.
With an IDE, you should be able to run your code and step through it line by line, using a debugger. This allows you to inspect the value of variables at runtime, to control the flow of the application, and to generally observe its behavior from the inside out, so to speak. In an ideal world, debugging wouldn’t be necessary; but when it is, having a tool designed for the task can be an enormous time saver. For you to incur the overhead of using an IDE, the debugging capability is essential.
Plugins and Customization
Any IDE upon which you come to rely should support plugins and customization. This is not unique to the IDE; many text editors also offer this. However, it is essential to being able to get the most out of the thing.
A plugin architecture allows you to customize its functionality (assuming it isn’t open source, in which case you could do this anyway), but it goes beyond that as well. Such an IDE also allows you to capitalize on third party offerings that can make you more productive. This might include everything from productivity add-ins to settings themes to code generators. Plugin functionality and a rich ecosystem dramatically expand the number of people and teams working to make your development experience a better one, so if you’re going to use an IDE, make sure it takes advantage.
I’m a huge proponent of automated unit testing, TDD, and writing clean code. Because of this, I’m also a huge proponent of one of the most critical concerns underlying all three of these practices: refactoring. Having a unit test suite is important for enabling fearless refactoring, one of TDD’s three steps is refactoring, and writing clean code only occurs via constant refactoring.
Refactoring, however, always comes with some degree of risk, minimal though it may be in a clean, test-driven codebase. An IDE with automated refactorings for things like “extract method” and “rename” reduces that risk even further by removing human error as a possible source of a problem. Of course, it’s also more efficient than doing it by hand. That’s a nice one-two punch, and these days, it’s not too much to ask from your IDE. Some of the mainstays have been doing it for a long time.
Intellisense and Navigation
The last important feature that I’ll mention basically amounts to navigation help. Again, you may see elements of this in some plain text editors or editors with plugins, but it tends to be a mainstay of an IDE. IDEs help you navigate to files, folders, and application resources, and they help you know what options you have as you type your code.
Any good IDE should have functionality like “go to definition” for a variable or method that you’re using. It should have functionality for allowing you to whip around your codebase without doing text searches or picking ponderously through files. It should organize all of the files in your solution in a hierarchical or otherwise easily searchable way and display them to you in an organized fashion so that you aren’t required to have advanced knowledge of your application’s entire file structure. When you’re typing your code, they should offer “Intellisense” or general type-ahead support to help you know, for instance, what methods on an object you can call.
Making the Choice Easier
If you’re on the fence and trying to decide between lightweight editors and heavyweight IDEs, there are plenty of voices out there that will try to persuade you one way or the other. As I mentioned, I’m not interested in joining in those voices — I think this is a decision you should make based on personal preference and experimentation.
Hopefully, you can take what I’ve written here and use it as a heuristic for choosing the right IDE, should you be leaning that way. It helps to know what’s reasonable to expect from an IDE so that, should you go the IDE route, you don’t wind up with the worst of both worlds.