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

Don't Build it Yourself

This post discusses the whether to buy or build software components needed for your application. The title should give you a clue as to which side of the discussion I land on. Someone Else's Code One of the behaviors that I've noticed is significantly more often exhibited by junior developers versus more experienced ones is the tendency to build everything from scratch. While I can appreciate the enthusiasm for wanting to create something better than has been done before, this is often simply a waste of time. For many of the software tasks you will want to accomplish, someone will have made a library of framework that does 95% of what you want out of the box, lets you configure or extend it to do another 4.9%, and you come to realize that 0.1% remaining wasn't all that important anyway. In fact, with the proliferation of open source software, many of these software packages are 100% customizable because you have access to all of the source code and can change it at will...

Some Thoughts on Software Estimation

"All programmers are optimists." Fred Brooks's adage is as true today as it was when he first penned the words. The truth is that people are naturally very poor estimators. We all have a tendency to believe everything will go more smoothly than it probably will. Things will work out just as we planned, assuming we bothered to plan at all. I encounter the reality of this often in my work. The first deadline passes, and we assure ourselves that we can catch up to meet the next one. The next deadline passes, and we finally come to terms with the reality that we're not going to make it. Then, we push the schedule back a week, when if we really reflected on the situation, we would realize we were probably a couple of months out from actually completing the project. The product gets later and later one day at a time. Lots of yelling and finger-pointing ensues. Management demands better estimates, but rejects any that don't fit with their view of when we "sh...

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...