Syntax Highlighting Can Be a Crutch and a Gate

Alonso Del Arte
Dec 2, 2020 · 6 min read
The source of a Java function in green interspersed with a pangram in red.
The source of a Java function in green interspersed with a pangram in red.

When you write a program in Java or almost any other mainstream programming language, syntax highlighting is almost taken for granted. It’s all too easy to jump to the faulty conclusion that syntax highlighting makes every optional element of the programming language (e.g., Java) completely unnecessary.

For example, supposedly having to write “this.” to distinguish instance members from local variables is outdated, a relic of the past, something that we should never do anymore now that everyone is using the exact same integrated development environment (IDE) with the exact same settings.

Consider this equals() override for the Fraction class, which hews very closely to the IntelliJ IDEA template:

An equality function in IntelliJ IDEA. The text of this image will be repeated in the article as plain text.
An equality function in IntelliJ IDEA. The text of this image will be repeated in the article as plain text.
An equals override for a class to represent fractions in Java, based on an IntelliJ IDEA template.

You can read the text in that image, right? By posting text as an image, I am making the assumption that you can read text in images. For the moment I will assume that you have read the text in the image.

Just because you’ve read the text surrounding that image of text doesn’t automatically mean that you can read the text in the image. For me to assume that you can would be making a flawed assumption.

If you can read the text in the screenshot, notice how the getClass() function, inherited from Object and marked final there, appears in a dull blue, while Fraction’s numerator and denominator fields appear in purple.

And the Java reserved words are in orange. Notice also that the much-maligned semicolons are in orange.

Of course this assumes that you’re using the default IntelliJ IDEA color scheme. That’s another bad assumption. Personally, I find the default theme a bit hard to read, especially when there are red squiggly lines in there.

IntelliJ has a high contrast dark theme that is much more readable, but I still prefer the light theme. Presumably the light theme was the only theme IntelliJ had in its early days.

Or maybe you’re using NetBeans or Eclipse, or some other Java IDE. The details of the default syntax highlighting differ, but in general, they make the same distinctions, such as between Java reserved words, class members and local variables.

But Java source also exists, or should also exist, in some cloud-based version control system, like GitHub. I’m not sure how long GitHub has had syntax highlighting, but it is quite different from the syntax highlighting in your IDE.

The following GitHub Gist shows the same equals() override from Fraction as the IntelliJ screenshot above.

Notice that GitHub doesn’t highlight the Java reserved words all the same way. Reserved words like “boolean” and “return” are highlighted in red, while reserved words like “this”, “null” and “true” are highlighted in blue.

But perhaps more importantly, Fraction’s numerator and denominator fields appear with no special formatting apart from function parameters like obj or local variables like other.

And of course GitHub isn’t the only cloud-based version control option. Nor is it the only website Java source appears on. Quite a bit of Java source winds up on Stack Overflow, which probably has its own syntax highlighting settings.

Also consider that IntelliJ IDEA is not the only Java IDE out there. I do use IntelliJ, but mostly for Scala.

For Java, I prefer Apache NetBeans, which has its own customizable syntax highlighting scheme, though it does highlight things in pretty much the same way IntelliJ does, distinguishing clearly between fields and local variables, etc.

I am aware of only two significant highlighting differences between NetBeans and IntelliJ: NetBeans bolds the first sentence of a Javadoc comment, while IntelliJ does not; and IntelliJ gives special highlighting for TODO comments, while NetBeans does not.

NetBeans renders operators and semicolons in black and reserved words in blue, while IntelliJ renders semicolons in the same orange as reserved words and operators are rendered in the same blue as parameters and local variables. I don’t consider this a significant difference, though.

Sublime Text and Visual Studio Code might also be options for Java programmers. Something tells me that Visual Studio Code is much more adept than Sublime Text at distinguishing class fields from local variables…

I could go on and on with this comparative analysis. The important point is that different Java IDEs have different syntax highlighting. If we’re relying on syntax highlighting to convey the meaning of our programs to other programmers, then we’re surely going to run into problems.

And what if one of our colleagues is colorblind, or completely blind? How does syntax highlighting work with adaptive technologies? How is syntax highlighting conveyed in Braille? I don’t actually know.

I’m sure the default color schemes for the major IDEs were chosen with red-green colorblindness (the most common form of colorblindness) in mind. A user can customize the colors in rather fine-grained detail if necessary.

I will now repeat the equals() override from Fraction without any syntax highlighting. It doesn’t look cool like the IntelliJ screenshot, it doesn’t look pretty like the GitHub Gist, but at least I can be much more certain that anyone who can read this paragraph can also read the Java source excerpt.

public boolean equals(Object obj) {
if (this == obj)
return true;
if (obj == null || this.getClass() != obj.getClass())
return false;
Fraction other = (Fraction) obj;
if (this.numerator != other.numerator)
return false;
return this.denominator == other.denominator;

Even without the syntax highlighting, it should be clear to any Java student who has gone beyond the basics that numerator and denominator are Fraction instance fields, that obj is a parameter and that other is a cast of obj (that’s unnecessary in Kotlin, because of a feature borrowed from Scala and trademarked by Kotlin as “smart casts”).

It could be argued that an equals() override is not the best example here. Most Java programmers just have their IDEs write it for them without at least quickly reviewing what the IDE wrote.

And, at least with immutable classes, equals() tends to require mostly only field comparisons, without any need for local variables other than the cast of obj. So syntax highlighting is not critical in an equals() override.

Where syntax highlighting might become critical is in a long unit, running, say, more than a hundred lines, and involving several class fields and local variables. Those definitely exist, likely in your older projects, when you didn’t know better than that.

Even with the best syntax highlighting and the most helpful comments, long units are resistant to refactoring and improvement. If it works, why mess with it? And then, when a problem arises, it’s difficult to pinpoint what needs to change and what can stay the same.

That program units be short is much more important than the syntax highlighting style or even the presence of syntax highlighting. Long units are a greater obstacle to the legibility of a program to other programmers than the absence of syntax highlighting.

If a unit is too long, break it up into smaller units. We might not agree on the threshold: four lines, as some suggest, is too draconian, in my opinion; and sixty lines, which is the minimum some IDEs will flag as too long, is too lenient, I think. So maybe meet in the middle at fifteen or twenty…

Syntax highlighting can be helpful, but it can also be a crutch. In my opinion, syntax highlighting is most useful in the moment of writing new lines in a program, when you make a mistake and syntax highlighting shows you that you’re not accessing what you thought you were accessing.

And maybe also when refactoring soon after getting a test to pass. But we should not rely on syntax highlighting to convey information that can be more clearly communicated by using slightly more letters or symbols.

Such reliance on syntax highlighting can be a gate that keeps out our colleagues who can’t see the syntax highlighting.

Alonso Del Arte

Written by

is a composer and photographer from Detroit, Michigan. He has been working on a Java program to display certain mathematical diagrams.

The Startup

Medium's largest active publication, followed by +756K people. Follow to join our community.

Alonso Del Arte

Written by

is a composer and photographer from Detroit, Michigan. He has been working on a Java program to display certain mathematical diagrams.

The Startup

Medium's largest active publication, followed by +756K people. Follow to join our community.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store