Syntax Highlighting makes your code look pretty, right? But is it just an aesthetic nicety, or does it have a more functional impact? And are there ways to improve it?

What is syntax highlighting?

Long ago, when I first learned to program, code looked like this:

Screens were low-res, low-refresh, and resolutely monochrome. Sometimes your code was light blue on dark blue, sometimes it was green on black, but it was always a single font, in a single color. I’m not sure how long I put up with this, but my best guess is that I started using syntax highlighting in the early 2000s, when the TextPad editor added it as a feature. Nowadays, my code looks like this:

I find this a lot more pleasant to work with, although I don’t often think about it: syntax highlighting is just there, an ever-present feature of pretty much any editor I care to pick up. Since terminal emulators finally managed to crack color, I’ve barely had to deal with a monochrome coding session, whether I’m in a GUI IDE with all the bells and whistles, or good old reliable Vim.

To the untrained eye, syntax highlighting is just another affectation us programmers like to pick up, a bit like keyboards with color backlighting or transparent PC cases. But this makes the fundamental mistake that syntax highlighting just sprays random colors over everything. Fair enough, if you don’t understand the actual code behind it, it may seem like that, but syntax highlighting is not at all random. The whole point is that “syntax” word: syntax highlighting reflects the underlying structure of our code, and that can be very useful indeed.

How can I use syntax highlighting?

To start, know that pretty much any modern editor, in any environment, should support syntax highlighting. If yours doesn’t, it’s probably time to upgrade. In fact, the only editors I know of that don’t support syntax highlighting are Windows Notepad and macOS TextEdit. Seriously, if you’re still using either of those for programming, please stop and pick up a better editor right now!

With a proper text editor in hand, try opening a .c file, a .js file, or any file containing code in your language of choice. Chances are, your editor is configured to detect the language type and apply syntax highlighting automatically.

If you’re really unlucky, your editor may be configured without syntax highlighting as the default, but this should be easy to change. For example, the Vim editor will read settings from a config file like /etc/vim/vimrc or ~/.vimrc. On my Ubuntu system, the relevant section looks like this:

In effect, this is saying “if syntax highlighting is available, turn it on.” You can toggle highlighting within your current Vim session, too: simply press colon to enter line mode, then type syntax off or syntax on.

Although I’m mainly talking about color in this article, some editors and fonts take things a step further, letting you highlight with bold, underline, and other formatting.

Is syntax highlighting beneficial?

The results from this study on the impact of syntax coloring suggest that syntax highlighting reduces task completion time. The experiment used eye tracking to determine that syntax highlighting helped participants focus on more significant parts of code.

In my own use, there’s a benefit that crops up again and again, that might not seem immediately obvious: syntax errors. Take this code example:

You may not immediately spot the syntax error, but color highlighting should make it much more obvious:

With syntax highlighting, it’s easy to notice the purple color running until the end of the line, where it includes the closing parenthesis and the semicolon character. This is a clear warning sign that there’s an error earlier in the line. When the bug is fixed, the output looks as it should, the purple color turning white once the correct quote character is in place:

With time, I’ve learned to spot these kinds of errors more efficiently, via syntax highlighting. It’s happened subconsciously, but my brain now seems attuned to the syntax differences that color highlighting brings to the fore. Color-highlighted code just looks “more wrong” when syntax errors are present.

Are there any disadvantages?

Of course, some programmers may find it harder to distinguish colors and certain color combinations in particular. This wouldn’t necessarily make it any worse than monochrome code, but it would definitely have an impact on any gains.

Some people may have cognitive conditions that amplify distractions, and color highlighting may be one such distraction. There are various techniques to encourage focus, so you may be able to mitigate this problem, but it’s worth experimenting with syntax highlighting to judge the benefits for yourself.

In theory, syntax highlighting comes with a performance hit, but you shouldn’t notice this unless you’re working with enormous files, in which case you probably have bigger problems! If you stick to good programming principles and use a stable, established text editor, you’re unlikely to notice any such issues.

Syntax highlighting used to be trickier to implement. Not only does an editor need to understand the syntax of a language, it also has to deal with partial code as it’s edited. A naive approach might cause frequent, distracting color changes to large blocks of text.

With the advent of the Language Server Protocol, a Microsoft initiative, this is less of a concern. Nowadays, text editors from Vim to Sublime Text have support for LSP built in, enabling features like advanced code completion and flawless syntax highlighting. But if an editor communicates with a remote language server over a network, some latency may be introduced.

The true benefits of syntax highlighting aren’t well understood, and neither are the factors affecting them. For example, if you frequently switch editors, they may use different color schemes—including none at all—or different methods of highlighting. This could reduce any benefits, or even counteract them.

And what about semantic highlighting?

As good as syntax highlighting may seem, it’s no magic wand. In fact, similar advances in text editors—like autocorrect and code completion—probably improve your programming life more than color does. But some people have theorized that syntax highlighting is just the beginning, and that color can be used in more advanced ways.

One such alternative is called semantic highlighting. This feature is actually present in tools including Visual Studio and Xcode, although you may be unfamiliar with it. Semantic highlighting focuses more on the underlying meaning of your code than its syntax.

The difference between syntax highlighting and semantic highlighting is subtle but, perhaps, significant. Take this example of a syntax-highlighted code snippet:

Take note of exactly which tokens are highlighted: keywords like function, let, and if; scalar values such as 1, 0, and the string; and syntax characters like [ and {. Now, have a look at an equivalent snippet with semantic highlighting, which might look like this:

This time, only names—functions, local variables, and parameters—are highlighted, but each is highlighted in a different color. This makes it easier to spot the lifetime of a variable and identify any typos that might change its name. It’s like a whole other way of visualizing the code structure, just by changing the color scheme.

---

Syntax highlighting is a convenient innovation that I’ve witnessed becoming the default. With the adoption of LSP and advances in AI, it’s just the beginning. Never before has it been so easy, and so aesthetically pleasing, to be a programmer.