For seven years I coded in C++ using Emacs. Four years ago, when I changed jobs, I switched to Java development using IntelliJ IDEA. Without a doubt, I am much more productive writing code in IntelliJ IDEA compared to using Emacs. Here’s why:
Coding is really something like 80% navigation, and only 20% actual writing, and where IntelliJ IDEA really shines is navigating the code base. For instance, say you want to add functionality to an existing class. Even if you know the class well, you need to check where the new code would fit in. Do you need to add a new state? What other classes are using the method you need to modify? These all require navigating the existing code.
Even when you write code there is a lot of navigation. What is the name of that method you want to use? What is the order of the arguments – is it a string first, and then an integer, or the other way around? What are the possible values of that enum?
Some of the navigation is within a file. The most common things I do within a file are: jump to the top/bottom of it, jump to the beginning/end of a line, select text, cut, copy, paste, search (incrementally) backwards and forwards, and commenting and un-commenting code. Both Emacs and IntelliJ IDEA have good commands and keybindings for all these operations.
But when it comes to navigating between files, IntelliJ IDEA has a big advantage. One of the most useful commands is Ctrl + B (go to declaration). As the name implies, you jump to where the variable, method or class is declared, even if it is in another file. Ctrl + Alt + Left takes you back. I use this all the time, often jumping several levels down before returning back to where I started.
A related navigation command is Ctrl + Alt + B, (Go to implementation). Use this command at the method name of an interface, and you get a pop-up list of all the places where this method is implemented, and you can select which one you want to go to (if there is only one implementation, you go straight there). The same goes for overridden methods.
The opposite of this is Ctrl + U (Go to super-method/super-class). If the caret is at the implementation of a method in an interface (shown by a little interface-symbol to the left of the method name), this command takes you to the interface itself.
When I want to see all the places where a method or variable is used (which I want to do a lot), I use Ctrl + Alt + F7 (Show usages). This gives you a pop-up list of all the usages, and you can easily navigate to each one. To find classes, I use Ctrl + N (Go to class), which lets you search using only the capital letters in the class name (“camel humps”), and * as wildcard. I also use ctrl + E a lot. It brings up a pop-up window of the 15 most recently used files (most recently used is at the top), and you just arrow down to that one you want and hit enter to navigate to it.
Yet another useful command is Ctrl + P (Parameter info). Use it at the arguments of methods and constructors to get a pop-up showing the types and names of the parameters, and where in the list you are. While this is not navigation in one sense, it would be in Emacs, since you would have to go to the file where the method or constructor is defined in order to find this information.
All of the above navigational commands are incredible time-savers. In Emacs you need to switch to the file yourself in order to find what you look for. In IntelliJ IDEA it’s automatic. In fact, I noticed that in my C++ and Emacs days, my classes tended to be bigger, and my methods fewer and longer compared to in Java. I think a reason for this is that navigation was easier when it was all in one file, but with the powerful navigation in IntelliJ IDEA it doesn’t matter much if functionality is spread out over several files.
Navigation aside, there are many other areas where IntelliJ IDEA has an edge. While both environments have syntax highlighting, IntelliJ IDEA has added a few useful features. Static methods and variables are shown in italics. Unused variables, methods or imports are greyed out. And of course IntelliJ IDEA will mark in red anything that is not syntactically correct as you type it. No need anymore to compile just to check the syntax – it’s done in real time for you.
IntelliJ IDEA also has some very useful features when actually writing code. First among those is auto-completion of names. Type a few letters of a variable or method name, hit Ctrl + space, and the name is expanded. Or use it to see what methods are available on an object by pressing Ctrl + space after the dot.
Another feature, which, according to the cool IntelliJ IDEA usage statistics, is the single feature I use the most, is syntax aware selection. If you press Ctrl + W repeatedly, it will select a bigger and bigger section of the code. For example, it can select a method name, then then expression, then the whole statement, then the containing block. Very useful when searching, indenting, commenting-out code etc.
And of course, there is refactoring support. In Emacs, if I wanted to change a method name, I would do a search and replace. But for each replace, I had to check to make sure I wasn’t accidentally changing something that shouldn’t be changed. If the method was public, I had to find all occurrences in other classes as well. In IntellJ IDEA, it’s a snap. Just select the method name, press Ctrl + F6, type the new name and hit enter. All occurrences in all files are replaced.
Unfounded Concerns about IDE:s
I often see comments about how if you’re using an IDE, you must be using the mouse and menus a lot. This is simply wrong. I love keyboard shortcuts in all applications, and I do as much as I can without reaching for the mouse. IntelliJ IDEA has great keybindings for almost all commands, and it’s easy to add new ones or modify existing ones. So there are really not a lot situations where you need to use the mouse and menus. All the commands I mentioned above I access with keyboard shortcuts.
Another unfounded concern is that you will only be able to do what is listed in the menus of the IDE. This too is an argument that doesn’t hold up. In my case, I do exactly what I did in Emacs, namely writing and editing code. The only difference is that it is a lot faster and more accurate in IntelliJ IDEA.
There is also a general unease that you’ll be “forced into the closed environment” of the IDE. Well, nothing stops you from using other tools when needed. The source tree is still there. Exit the IDE and use whatever tools you need, then get back in again. For example, I’ll sometimes need to grep through code that spans several IntelliJ IDEA projects. In those cases, I’ll just use grep with a suitable reg exp. No big deal.
Finally, I have seen the argument that the IDE adds configuration and meta-data files all over. In the IntellJ IDEA case, there are only 3 project files added at the root of the source tree. That’s it. Very unobtrusive.
You don’t know what you are missing…
The funny thing is, before I switched I was very happy using Emacs. I had learnt a lot of short cuts, and I had become really good at editing. I was also good at using grep, find and other Unix commands on the source tree, and didn’t feel that I lacked any tools. Quick side-note: the best source for Unix command line tools is Unix Power Tools. Pure gold on the command line.
When I started at Symsoft, pretty much all developers were using IntelliJ IDEA, so it was only natural to try it out. I quickly saw what you could do with it, and never looked back. In fact, once I realized all the cool things it could do, I insisted on showing my former coworkers what it could do. Whenever I had lunch with one of them, I would bring them up to my office and show them some of IntelliJ IDEA’s tricks. Seeing is believing.
…but there is always room for a good editor
There is always room for a good text editor. Even though I don’t use Emacs for Java, I still use Emacs pretty much every day. It’s my editor of choice for text files, and I use it for the occasional bash and ruby scripts.
However, just the other day, the subject of text editors came up with a colleague of mine. He mentioned that he had just started to learn Vim. In the spirit of making sure I know what I’m missing, I will give it a try too. So for a while now, I’ll replace Emacs with Vim. Let’s see how that turns out.