Editorial Note: I originally wrote this post for the Monitis blog. You can check out the original here, at their site. While you’re there, take a look at their offerings for monitoring all of your production concerns and infrastructure.
Few subjects in programming can get as contentious as quickly as, “what should I use to edit my code?” Before you even get to the subject of “which one,” vigorous debates emerge over “what kind?” This cordial Quora question with roughly 6 billion answers serves as an example of this. Text editor or Integrated Development Environment (IDE)?
Only after that perilous decision do you arrive at the “which one debate.” So furious has this debate proved that Wikpedia has an “Editor War” entry. It describes the choice between the Emacs and VI editors. The usage of “war” is a joke. But only kind of.
So against this backdrop, you might regard the choice as one fraught with peril. Pick incorrectly and risk the scorn of your peers. That’s a joke. But only kind of.
Fortunately, for the purposes of guidance, at least, I count myself a pragmatist mercenary. In other words, I come from the relatively small camp of software developers without much strong preference about any of it. I have spent years with each of the following: Visual Studio, Eclipse, IntelliJ, Emacs, Pico, Nano, Scite, SublimeText and Notepad++. And I’m probably forgetting some. All have their perks and foibles, but I prefer to keep my options open and let context guide me.
So, face with the need to pick new tooling, how should you handle it? Today, I’ll offer some advice on heuristics for selecting an IDE or text editor.
Make a Quick List of Your Needs
First things first. Do what you would do when contemplating any sort of consumer decision. Make a list of your needs and wants.
For instance, say you were buying a refrigerator. You’d need a certain size to fit your space, and you’d need a certain amount of storage capacity. You might then want a chrome finish and an ice maker. Contemplate the tool you’ll use for writing code in this same fashion, for starters. You may have non-negotiable needs around operating system and programming language, and more fluid wants around features.
But also bear in mind context. For example, do you specifically need a tool to work on one specific project at the office? Or do you want something versatile that you’ll use everywhere, across various languages and technologies?
Now, combine these two lines of thinking and you will probably have narrowed the field considerably. And you need to narrow the field, since a surprisingly daunting number of options exist out there. Easier to choose among 2 or 3 than from hundreds.