A collection of characters, stories, and other elements
Developers read a lot. We read books, blog posts, documentation, but mostly, we read code. We read so much code, that many of us have become quite particular about how it is displayed.
Since searching and reading code are intrinsically related, the Sourcegraph design team began to study how we could improve the display of code in Sourcegraph. Our goal is to make reading code easier, so it makes sense that we would study the place developers can decide exactly how their code should look: their editors.
While our research is far from complete, we thought you might find a breakdown of the visual characteristics of where our team writes code of interest.
Three-quarters of our engineers preferred a dark theme over a light theme. Curiously, the majority of our dark mode users chose a lower contrast between code and background than their light theme oriented peers. Background colors averaged 85% black and the primary code color to background contrast ratio averaged 9 to 1. This seems to contradict the dark themes offered by many other developer tools, where dark is often interpreted as near 100% black and text is often 100% white.
Conversely, all light mode users at Sourcegraph prefer the maximum contrast with 100% white backgrounds and a black primary code color.
Contrast representative of typical dark and light modes.
There are clearly two camps: those who use an Integrated Developer Environment (IDE), which in this case is mainly VS Code, and terminal-based editors such as neovim/vim/emacs users. Editor users had around 96% of editor screen real estate dedicated to code. IDE users had from 80% to 90% of their screens dedicated to code or the terminal, with the rest occupied by file trees and other UIs such as menus and tabs.
Over half of our engineers customize their programing font. Among these users, FiraCode was the most popular choice, followed by JetBrains Mono. Other fonts include MonoStroom, Cascadia Code, and Hack.
Why customize your programming font? Glad you asked! Code, like no other language, can be dramatically altered by the slightest change. Programming fonts make it easier to distinguish characters and can render operators with custom ligatures to enhance readability. These traits can reduce errors and lead to better applications.
While these results are not statistically significant, one trend does stand out: developers will customize their environments to improve the readability of code. Keep scrolling to check out some of the setups Sourcegraphers have deployed to help them create universal code search.
What editors, themes and fonts do you use? Tweet us at @sourcegraph to share your thoughts and images. Make sure to not include sensitive information in any screens you share!
As part of our research, we asked Sourcegraph engineers to share their set up. Here’s a look at 17 individual setups in greater detail.
I use a mixture of Visual Studio Code with more or less the recommended language support plugins and nothing else (sometimes in remote mode to a devbox in the cloud, sometimes locally), and Neovim with airline for a better statusbar and coc.nvim to get the same LSP magic as you get in VSCode. I’ve tried the native LSP client in neovim nightlies, but I hit too many rough edges. I tend to keep my editors as just editors; I don’t use builtin terminals or debugging capabilities.
Styling wise, everything is in light mode. I find it helps me focus, and I keep dark mode for late night phone usage when I should be sleeping. I use Fira Code as a font because I love ligatures, even if I don’t always love its serifs. Like Keegan, I’m also very keyboard driven.
In terms of general workflow, I tend to be very single window focused: I run everything in a separate fullscreen window on a separate workspace in Sway on Arch Linux, and use hotkeys to switch between workspaces. (1 is always Firefox; 2 is kitty; 3 is personal chat; 4 is Slack; 5 is VSCode; 6+ are used for ad hoc one offs.) Generally speaking, I have as little chrome as possible, besides Waybar. Menu bars are usually disabled once I know hot keys, and I have Sway configured to disable title bars unless the workspace has multiple tiled windows or the window is floating for minimal distraction.
It’s a disaster (“method to the madness”), but:
In my editor I keep open every file (usually <60) that I have interacted with when working on my current project (in this case, the backend for Code Insights.) I do not ever open files that I am not constantly referencing, and if I need to do a one-off search I use a Sourcegraph browser tab. On the far left tab I have a single scratch doc with random notes. I use the VS Code search feature to jump between code I am working on, with tricks like
) GoMethod( to find Go methods. I have gopls (the Go langserver) disabled because I often find it taking too many resources and/or preventing me from saving Go files while it tries to run formatting operations.
VSCode to write lots of code:
I basically do everything either in tmux or in the browser. In tmux I spawn lots of windows/shells as I need them, but have different sessions for work, private recreational programming, and other things. In the browser I always have 3 pinned tabs (for gmail accounts and other email account). I also use Alfred a lot (to search Sourcegraph for example).
I’m experimenting with the Nova editor alongside VSCode, which replaced Sublime Text 2. I don’t have any standard window setup, shifting as I need for any given design, research, or programming need. I’ve been using the fantastic Operator Mono font with ligatures and italics for years.
We want to see your setup too! Tweet it to us @sourcegraph.