Skip to main content

Yet Another Post About Text Editors

Here's a debate that will never end as long as people are writing code: which text editor is superior? While there is one that I regularly use, I really think the answer to this question is none of them. They all have their strengths and limitations. It often comes personal preference, convenience and the nature of the tasks you typically need to accomplish. What is less often discussed is why we should even bother with using a text editor at all.

What is a Text Editor?

I'm going to back up a bit though. Let's first ask: what is a text editor? A text editor is a program with the primary function of editing and manipulating characters on a screen and writing them to and reading them from files. While text editors are very commonly used in software development, they are not restricted to that purpose. Anyone who has any textual content to write or edit can potentially benefit from using a text editor. Text editors generally don't provide much in the way of visual formatting such as what you would find with a word processor like Microsoft Word or Pages. Some popular text editors include Emacs, Vim, Sublime, Notepad++ and TextWrangler.

Text editors don't attempt to provide many of the features that IDEs do. Now, we will ask ourselves: what is an IDE? Modern IDEs (Integrated Development Environments) provide text-editing capabilities plus many, many more great features useful for software development that text editors don't supply or may provide in very rudimentary forms. Such features may include, syntax checking, project structure management, static code analysis, compilation, debugging, source control, auto-completion, detailed syntax highlighting, performance analysis and more. Some popular IDEs include Eclipse, Visual Studio, Xcode and IntelliJ. These tools are indispensable for software development. So, if we know we're going to use an IDE anyway, which does allow us to edit our source code files, why employ yet another tool to do that job that an existing tool can already do?

Why Use a Text Editor?

The most important reason is efficiency. While some text editors are more feature-bloated than others, in general, they do one thing and do it well. IDEs tend to take a significant amount of time to launch, suck up significant memory and processing resources and are not always very responsive. A good text editor, on the other hand, launches almost instantaneously, barely registers in terms of resources usage, and responds to your input immediately.

There is no magic in this; it is simply that a text editor doesn't attempt to do (much of) anything beyond manipulating text. Unlike you IDE, it is not trying to find syntax errors by parsing all of your code. It's not trying to interpret which of your variables are local and which are class members. It's not attempting to auto-complete every statement you type by looking up all of the available methods for you when you already know the one that you want.

Another great thing about text editors is that their interfaces come designed and configured to maximize text-editing speed. The most convenient keyboard shortcuts are mapped to common text manipulation commands rather than to launching a debugger or refreshing project dependencies. While there are ways to make your IDE respond to keyboard input more like a text editor, such as Vim keyboard bindings for Visual Studio, it's not a perfect mapping, it requires extra steps to configure, and it still doesn't avoid the responsiveness issues mentioned above.

This interface efficiency is very important, as most software developers will spend a substantial portion of their time writing and editing code. Your fingers and wrists can fatigue and wear out both in the short term and the long term. Minimizing the number of keystrokes required to get your work done has real, tangible benefits to the health of your hands. Text editors contain all kinds of shortcuts to help you get the most done with the least number of keystrokes. In the end, to the fullest extent possible, you want your brain to be the bottleneck, not your hands or your development tools. A good text editor will allow you to create and modify code as quickly as you can think of it much of the time.

In order to exemplify this, I'll mention a few of my favorite features from my text editor of choice: Vim. While Vim's default normal mode can put people off very quickly because we all expect our unadorned alphanumeric keystrokes to put text on the screen, you can come to recognize the efficiency of it when you realize how many very common tasks can be accomplished with a single keystroke. Vim's '.' command is an incredible example. It repeats whatever you did last in a single keystroke. Single-key undo with 'u' is another of my favorites. Undo is an extremely frequent operation for many of us, so why should we have to press two keys to execute it? Then there's the substitute command ':s' that allows for find and replace with a very robust regular expression syntax without ever having to access a menu or click buttons in a dialog box. This is very much the tip of the iceberg, but it indicates the power available to you with very limited keypresses rather than Ctrl-Alt-Shift combinations that are more typical of an IDE.

Not Recommended for Beginners

One thing I would like to note that I discovered the hard way. When you're just starting out learning how to write code for the first time, I do recommend you write your code in an IDE and skip the text editor for a while. Someone recommended Vim to me when I was just starting out, and I hated it. It was frustrating to learn, and it didn't provide any of the guidance that really benefits beginners, which you will get from an IDE. Once you gain some experience though, you will reach a point where you can greatly benefit from the efficiency of a text editor. When I started working on larger projects and became comfortable with the language I was working with, Vim became an indispensable tool rather than a frustrating impediment.

So, don't throw away your IDE, but do give a text editor a try if you haven't been using one. Be patient with it and spend some time learning how to use it. I'm confident you will become more efficient at writing and editing code if you do.

Comments

Popular posts from this blog

Books That Have Influenced Me and Why

A mantra that I often repeat to myself is, "Don't abandon the behaviors and habits that made you successful." I believe this trap is actually much easier to fall into than most people realize. You can sometimes observe it in the context of a professional sporting event such as American football. One team might dominate the game, playing exceptionally well for the first three quarters. Then, as they sit with a comfortable lead, you see a shift in their strategy. They start to play more conservatively, running the ball more often than they had. Their defense shifts to a "prevent" formation, designed to emphasize stopping any big plays by the other team while putting less pressure on the short game. The leading team often looks awkward in this mode. They have switched their perspective from that of pursuing victory to that of avoiding defeat. They have stopped executing in the way that gained them the lead in the first place. I have seen more than one game ult

Code Maintenance Requires More Than Testing

Writing and running automated tests can go a long way to help maintain the quality and reliability of a code base. Tests help ensure the code you've written executes the way you expect it to. However, even though automated tests are a great tool for helping to ensure quality over the years in which people will contribute to the code, they are not sufficient in and of themselves. It may be inevitable that all software products will reach a point of obsolescence no matter how much work is done to keep them current. The inherent problem is that if we view tests as constraints upon what the software system under test can be, then as we add more and more tests over the years, we will have more and more constraints on the shape our software is allowed to take. It then seems we must reach an inevitable point where we can no longer change our software system without violating a constraint, i.e. causing a test to fail. In more practical terms, we'll more likely first reach a situat

Notions of Debugging

Bugs can be really evasive and produce some surprising, even "impossible" behaviors. Part of a software developer's job is to relentlessly hunt them down and destroy them. However, often at least half the battle is finding them to begin with. The best debuggers I have seen rely a lot on experience, both experience with the application and experience with debugging in general. The former is situation-specific, and there many not be any good ways to advance in that regard other than practice. However, we can extract some information pertaining to good debugging practices in general. Dig for Clues Using All Available Resources The first step in debugging an issue is ideally to reproduce the problem. This isn't always possible, but if you want any significant level of confidence that you have fixed a bug, you need to observe the broken behavior and understand how to trigger it from a user's perspective. Sometimes we're lucky, and a tester has taken the time to