In the programming community, there are an overwhelming number of opinions about text editors, IDEs, and other related tools. There are so many options out there and so many strong opinions that it’s really difficult to find the best tool for the job.
However, finding the right editor is extremely important! After all, text is the basic element of programming, so choosing a tool to manipulate text is one of the most fundamental decisions a programmer can make.
In my experience, developers will often use the first IDE or editor that they became comfortable with. A Vim user often only uses Vim. An Eclipse user will often only use Eclipse. I’ve even seen embedded C developers write code for an ARM target in Visual Studio because they were comfortable in Visual Studio and didn’t know anything else.
When making the decision of text editor vs. IDE, there are a few things you should keep in mind.
1. There is no one tool to rule them all.
Just as in any other trade, there is no one single tool that is correct for all situations. A carpenter would never say that a table saw is the only saw to use. A table saw is really good at quickly making straight and accurate cuts, but it is bulky and not designed for making intricate cuts. A jigsaw, on the other hand, is flexible, small, and can be used on many types of materials. Each is appropriate for certain jobs, but a carpenter who used the same saw for every wood-cutting situation would be a terrible carpenter.
Similarly, software developers can’t rely on a single editor/IDE as the correct tool for all situations. Sure, IDEs can be powerful and elegant, filled to the brim with useful utilities (compilers, debuggers, static analyzers, contextual code completions, project navigation/overviews, etc.). Sometimes IDEs are actually required, especially if you are working with proprietary tooling (e.g. Visual Studio). However, they can also be overkill, actually taking away from the programming experience. And quite often, IDEs lack one of the fundamentals of programming: efficient text editing.
This is where the basic text editors really shine, because their only job is to be the best text editor. They are usually slim, fast, and no-nonsense. There are many times as a developer when all you really want to do is just write code efficiently. You don’t need a project overview, you don’t need super-intelligent code completion (although I personally think that basic word completion is a must), and you don’t need the full stack of integrated tools. In these cases, a simple (yet powerful) text editor is the right tool for the job.
2. You should be proficient in one editor.
I strongly believe that every developer should know one powerful editor and use it whenever possible, but the editor you choose is a matter of personal preference. For me, it’s Vim. For others, it may be Emacs, SublimeText, Atom, Notepad++, or a slew of others.
Whichever you choose, a good editor should:
- Allow for (and encourage) quick and efficient text manipulation. With a few keystrokes, you should be able to add, move, delete, copy, and replace any chunk of text. This is where Vim really shines, in my opinion. Any time you have to touch your mouse in order to edit text is a mental distraction and reduces efficiency. However, even more GUI-heavy tools like Sublime and Notepad++ allow for some efficient editing tricks with the mouse.
- Be available in all environments in which you work. If you are ever going to do system administration and will need to SSH to remote machines, then learning Vim or Emacs would be advantageous.
- Be configurable to your preferences, such as keystroke bindings, color schemes, fonts, etc. If you are working with a team of developers, sharing a common set of keystroke bindings can be very useful, allowing any developer to work on any other developer’s machine without being hindered.
- Be under active development. If your editor hasn’t been updated in three years, then it’s probably already stale. You want an editor that will continue to be relevant in future years. It should adopt new languages, formats, and external tool integrations/plugins. Open-source tools are almost always the best in this category.
- Minimize mental distractions while coding. Basic features like auto-indentation, proper syntax highlighting, and word completion are extremely helpful for keeping your mental energy focused on important decisions. Instead of interrupting your train of thought with questions like, “What was the name of that method again?”, “Where is the end of this if-statement?”, or “Did I mix up double and single quotes on this string?”, you can rely on your editor to answer those questions for you.
3. Find the right tool for the job at hand.
The answer to “Which tool to use?” is simple: It depends. A good programmer should always be evaluating his or her needs with regards to the project at hand. If you are new to a project with a large codebase and are constantly struggling to find your way around in the code, then you should probably use an IDE with good project overview/navigation tools. If you are working on a project with open-source tooling and have a good grip on the source code, then it’s likely that a basic editor is the right choice. If you need a particular IDE because of its proprietary tooling but hate the editor features of that IDE, then you should use an editor for coding and the IDE for its tooling.
As a programmer, the choice of editor/IDE is an important one, and it should not be a one-time decision. You should always be re-evaluating your choice and making changes wherever needed. In fact, it can be helpful to drop your favorite tool for a while and pick up a new one. The worst thing you can do is to pigeonhole yourself into a particular tool or to be overly loyal to a particular tool. A diverse tool set is always a good thing.
Check out some related Spin posts for good information about particular tools that Atomic developers have used.
Notepad++ for life !