There is a lot that modern IDEs do well, but uncluttered writing space isn’t one of them. Once you add the various views of your project, the debug window, the source control window and various other important panes you’re left with a tiny viewport into your code. The visual clutter can be disabled of course, but you’ll get it back sooner or later. When you switch back to debug mode or build mode, for example.

Compare this to an editor that shows nothing but a bunch of windows/buffers/frames into your source code and maybe menu and status bars. You can make use of all the screen real estate that your large monitor gives you – you have a large monitor, don’t you – instead of sharing it with those windows or panes that the IDE needs to display its other functions. That has a big advantage that you get the biggest possible viewport into your code, so you can get a view of as much context as your monitor will accommodate while you are writing code. That’s a big win for me.

Pure programming text editors are also designed to do one thing, and do it well – edit source code. Well, “do it well” within reason, at least the ones that have been around for a while do it well and tend to be a more powerful than your average IDE’s text editor when it comes to editing text. Yes, they won’t have some features that an IDE gives you – usually, code completion and refactoring tools are more powerful in your IDE – but keep in mind that the main purpose of a text editor is to, well, edit text and do that well.

Of course you can write good code with your IDE’s built in editor, with proper formatting and all that. Just keep in mind that it’s a multifunction tool and like a Leatherman, it’s very useful in many cases but sometimes you need a chef’s knife or a scalpel. And when you need that, you need it bad.

So, after the preamble, what do I consider the must-have features for a good programming editor? There are surprisingly few:

  • Speed and responsiveness. I had to learn touch type because of the Kinesis ergonomic keyboards I have to use and as a side effect I can now keep my eyes on the editor and notice any sort of delay between the touching a key and the corresponding action on the screen. Given how fast our computers are I find this irritating so certain IDEs (don’t want to name names here) are really bugging me because they seem to ‘lag’ behind my typing and thus the expression of  my thoughts. That goes for any sort of interaction by the way, including opening files and switching buffers – it’s not really acceptable for an IDE or editor to take some “thinking time” that’s measured in seconds just to open another file.
  • The ability to edit really large files. OK, so your source file should be a reasonable size – I tend to cringe if they hit 2000 lines – but sometimes you have to look into a log file with something a little more sophisticated than ‘more’ or ‘tail’. Your editor shouldn’t fall over because the file is a few tens of megabytes in size.
  • Syntax highlighting. It’s a programming editor, it’s a basic need.
  • Source control integration. Same reason.
  • Allow me to keep a large number of files open at and given time and possibly have multiple windows open that I can use on multiple monitors. And for extra brownie points, offer me multiple views into the same file at the same time.
  • Rectangular blocks for cutting & pasting. If you ever had to use a feature like it, you know how useful it is the three times a year you need it.
  • It should be programmable to a certain extent. We do enough repetitive work as is and need all the help we can get.
  • Some sort of code completion is nice, even if it’s just to cut down on the number of typos. Depends a little on the language you’re coding in, in some it’s more useful or necessary than others. For example, for writing modern style Java I would prefer to have code completion, for Ruby code I don’t really feel the need.

Not really that long a list, is it? But I still find it surprising how many editors or IDEs don’t tick all the boxes on the above list.

Anyway, spend some time trying out a couple of editors, you might find one that you like. It doesn’t have to be Emacs (I had to get that in here, didn’t I?) but there are enough other editors out there that are worth a try. Find one you like and then spend time learning its capabilities. While cranking out source code is often a smaller part of our work than we think it is or should be, if you can improve the rate at which you can write code you will improve your productivity because it’s easier to stay in the zone if your code flows with your thoughts. Even if you have to slow down your thoughts because you can’t type as fast as you can think – well, at least I can’t.

Leave a Reply