Code Editor Essentials part II: Tips for Searching Files
Before you can position a cursor in a file, you first need to locate the file itself. Normally this is done with an OS-default “Open file…” dialog, but there are other options, which are more efficient. Here are some helpful tips for finding files!
The normal mode of operation for the standard dialogs is browsing. When you open the dialog, you get a list of files and directories in a certain location. You then click on a directory and are presented with a list of files and directories inside. You continue this process until you find the intended file. Sometimes you have to backtrack, wasting a lot of time.
In contrast, searching is much more efficient. Project directories tend to be of a formidable size and depth, and searching lets you quickly narrow down the number of files you need to examine before you can open the correct one.
Many editors offer this feature in different ways. Some, like PyCharm or SublimeText, offer a single input box for searching for files and additionally for any other entity existing inside your project (like classes). Some, like in the case of my Emacs configuration, offer a specialized tool for searching for files only. An important quality of such tools is that they don’t force you to enter the path exactly, allowing you only to type parts of it and performing fuzzy matching. Well-done tools for this also let you easily list the contents of a directory(ies) matched.
These file finders most often require you to have a project set up so that they can index your files for speed of searching. But sometimes you find yourself in a directory far away from your project root, and you’d like to find a file that’s somewhere *there*. In this case, most editors offer an equivalent of normal Unix `find` command. In Emacs you can use it like so:
Many editors provide a feature useful for both cases: bookmarks. Just like in web browsers you can bookmark any page, in editors you can bookmark any file or, more specifically, any line in any file. You can then view your bookmarks and search through them. Because you’re likely to have fewer bookmarks than files in a project, searching through bookmarks is going to be faster, and even browsing bookmarks is sometimes viable. Emacs has a couple different interfaces for bookmarks; here you can see my preferred one:
If you don’t remember how the file was named or in what directory to look for it, not all is lost. If you know that you worked on it not that long ago, it may be good to take a look at a list of last opened files. All editors have something to this effect. To be the most useful, this feature should allow customizing how many files to keep (I use 100). It also should allow for easy searching in the list. Here’s how this looks in Emacs:
Find in Files
Sometimes you don’t know what is the name of a file you’re looking for, but you know that it contains some particular string. Most editors offer some `find + grep`-like functionality for this, it’s sometimes called “Find in Files.” In Emacs, like usual, there are many options to choose from:
So far everything we did would work no matter what was the content of files we were looking for, however, as programmers we often work with files formatted in a certain way. Such files have structure and elements like classes or functions that we’d like to search, too. The most basic tool for this is a “project tree” feature, which looks just like a directory tree but adds each files classes and functions below it:
Such views are quite nice, especially for getting a high-level overview of a project, but are not perfect. As mentioned before, searching is almost always faster than browsing. So it’s essential to have a way to search for a certain class or a function definition, no matter in what file or directory it’s placed. Some editors support this as a part of “open anything” feature, others make it a separate feature. In Emacs there are many different packages for this, here you can see one of them:
Go to definition
The last feature for finding files I want to describe probably is one of the most often used. Some editors call it “Go to definition.” It’s simple: when you position the cursor on a name you press a shortcut and the file containing a definition for the name opens. Your editor needs to understand your language syntax to do this reliably because it needs to be able to distinguish definition from usages. While we’re at it, we should also be able to search for the usages.
To wrap everything up
Searching is usually better than browsing. Browsing might be helpful when you get to know an existing project but when working with a code you already know it’s usually faster and more efficient to do the searching. It’s always good to know what your editor is capable of even if you don’t choose to use the features. What are your tips for searching?
Subscribe to our newsletter
Want to receive a fortnightly round up of the latest tech updates? Subscribe to our free newsletter. No spam, just insightful content covering design, development, AI and much more.