Syntax Highlighting Is Backwards (2018)

[lgeorget]

As with a lot of things, this is ultimately a matter of personal preferences, and the compiler could not care less about how your code is displayed in your editor. So, the question is not whether is's "backwards" or not, it's only a matter a finding the highlighting theme that subjectively suits you.

In my case, I prefer having the keywords highlighted and comments less visible than the code. Why? Because code is not something I read linearly. Having the syntactic markers highlighted helps me visually navigate from blocks to blocks. And it makes it much easier to spot missing curly braces, parentheses, etc.

[markbnj]

> Having the syntactic markers highlighted helps me visually navigate from blocks to blocks.

Exactly, and I second the personal preference point. It's not so much about highlighting specific things to call attention to them as it is about breaking up a homogeneous block of mixed text and whitespace into something structured and horizontally navigable.

[jeltz]

Same preference here. I use highlighted keywords to navigate and find stuff quickly in files. Especially important is highlight of some keywords like "return" so I do not miss any early returns.

[SlowRobotAhead]

This is a good counter argument to the article. I know instantly what a switch statement does, but if I have big bold markers for where a switch and it’s cases are, that helps me jump to the block I’m looking for.

In the case of faint comments, I may need to slow down and actually read them if they’re a little less visible. I also know instantly that comments aren’t code and I don’t want all my code faint so just them being different from each other is enough for me.

Article makes good points but doesn’t seem like it’s for me.

[simion314]

I also use red color for global variables, helps me to detect if I forget a var or I made a typo, also I use different colors for local variables and method parameters.

[drinchev]

Sadly this won't work when you read code online. GitHub shows comments gray, as well as StackOverflow. This makes one step in the right direction - movement to highlight the important things, rather than everything.

[Finnucane]

Maybe what would work is some sort of show/hide comments. That is, at a keystroke be able to flip the contrast on comments to read them, then reverse it to look at the code.

[beaker52]

Drawing attention to language constructs like if and return helps you visually identify patterns. When you need to know details you look into the specific code.

Highlighting the noisiest and least uniform parts of code is probably not what I really want. I don't want to draw references from an entire book in title case, with tiny section and chapter titles for example.

Highlighting helps me identify code from a distance, it doesn't help me read it. It's about visual cues that eventually form into heuristics that save me time as I roam around a codebase. "Oh this is one of those" "that's not the kind of function that I'm looking for"

[bastawhiz]

This largely seems like an issue with the author's IDE or theme, not an issue with syntax highlighting. I immediately assumed the first screenshot was what they were proposing since it's not like the syntax highlighting that I have used in vi, sublime, visual studio, or vscode. The actual proposal, to my eyes, removes highlighting entirely: I can't differentiate the shades well at all, and the "bold" commented text is even less visually distinct than in the original.

Semi-related: do folks actually use very low contrast themes like the one in the screenshot? My vision is better than 20 20 and reading light gray on white (or dark gray on black, for that matter) is a terrible strain on my eyes.

Edit: it appears the author has a dark mode theme on their blog which changes the colors of the screenshots

[csdvrx]

Yes, I use a low contrast theme, light grey on yellow.

My vim is Solarized based so I can invert colors at night and get more contrast by collapsing the RGB values into just red using NegativeScreen.

My bash is more custom: to be even lower contrast, I don't use colors except for when commands return with an error code. Instead, I use font attributes a lot (bold, italics, faint, etc) and I timestamp my commands so when I check my records I can easily find which parts took me the longest to think and do. The command I am typing has the current directory in bold to quickly remind me as I usually have several terminals opened.

Here is what my bash (where I spend the most time in) and vi looks like: https://raw.githubusercontent.com/csdvrx/sixel-tmux/master/s...

My bash has changed to match vi: the # prompt and red error codes now use the background color with: \e[2;48;2;215;215;175m\]#[\e[0m\]

[Mikeb85]

I personally like relatively low contrast colours on a dark background. High contrast themes put strain on my eyes.

[squeaky-clean]

PyCharm is extremely configurable. I've probably spent a whole day or more setting up my preferred syntax highlighting and keybindings.

I think the default highlighting is fine because it's what's best for beginners, highlighting language keywords and such.

[akkartik]

Not all comments are worth highlighting: http://akkartik.name/post/2012-11-24-18-10-36-soc

For the last 6 years I use three colors for comments: https://i.imgur.com/vU783Xo_d.jpg?maxwidth=640&shape=thumb&f...

If you have a configurable editor you can find more useful things to highlight in the code as well: https://www.reddit.com/r/programming/comments/1w76um/comment...

[laughinghan]

I thought this was going to be about semantic coloring: https://medium.com/@evnbr/coding-in-color-3a6db2743a1e

I think semantic coloring makes way more sense than this or syntax highlighting because it helps you see the actual flow of the code, unlike syntax highlighting which helps you see the syntactic structure of the code (should be second nature to any expert) and unlike this which merely helps you see comments (which even in the example in the blogpost is secondary information to what the code actually does, which is usually the main thing I want to know when I read code).

[hiccuphippo]

Intellij highlights all uses of a variable when you put the cursor on top of it, which I think is enough for me.

[maaaats]

I tried rainbow/semantic coloring for a while, but felt it messed with my pattern recognizion. And when everything is highlighted, nothing is, it felt loud.

[uxp]

Do I have some weird rendering issue with this website, or do both of these snippets of code have terrible readability and highlighting? If I had to write code using an IDE or editor with this scheme I'd quit my career and go into small engine repair.

https://imgur.com/a/vS2EldV

[pcr910303]

I'm pretty sure it's b.c. you have dark mode turned on & the CSS didn't consider code snippets.

Try turning them off, it'll look much better.

[SahAssar]

I think this is what it is supposed to look like: https://imgur.com/a/OHkBb8Q

[jeltz]

Nope, it looks the same to me and I have a screen with high contrast and high brightness. Both his examples are very hard to read. And I have done color blindness tests and know I am not color blind.

Another thing: I think one thing he is missing is how important it is to see at a glance where function definitions are and where possible early returns are. The first example highlights def (function definitions), return (possible early return) and the return type (arguably not that important in most cases).

[benkuhn]

Sorry about that! I built dark mode after writing this post and it broke the main text color inside the `pre`s, which should have been #222. Should be fixed now.

[czr]

hack to switch to light mode, if you don't want to do it systemwide (paste into console):

    Array.from(document.styleSheets).forEach(ss => Array.from(ss.rules).forEach((ssr,i) => {if (ssr.cssText && ssr.cssText.includes("dark")) {ssr.parentStyleSheet.deleteRule(i)}}))

[FPGAhacker]

That’s what it looked like for me. I thought maybe it looked illegible to me due to red-green color deficiency.

[saagarjha]

The text is black for me on my iPhone.

[buboard]

Highlighting is meant to create "visual handles" on the code so your eyes can quickly jump to beginning/end of function/loop to figure out the scope of the comment. If you put the comment first , it's like replacing the floor numbers in an elevator with the warning signs. At most , you'd highlight just the word "WARNING:" or "TODO:" etc. Anything more is clutter

[whalesalad]

I totally agree with the sentiment of the author but the execution is really terrible. I'm not sure how the end product is at all better. It's appearing as like #CCC or #EEE on a white background. Screenshot: https://s3.whalesalad.com/images/hn/syntax.png

My favorite color scheme for a long time has been Made of Code, which I have slowly tweaked over the years. It has particularly great rendering of comments, where the line of the comment has a background color that takes up the entire row.

Example 1: https://s3.whalesalad.com/syntax/made-of-code-tweaked.png

Example 2: https://s3.whalesalad.com/syntax/made-of-code-tweaked-2.png

Theme file (Textmate/Sublime): https://s3.whalesalad.com/syntax/whalesalad-2.tmTheme

[bastawhiz]

Try disabling dark mode on your device.

[dystroy]

We're really good at parsing code, thanks to languages designed to be easy to read and to our style guides (unless we don't have one, of course). Highlighting keywords is uselessly tiring for the eyes IMO.

What matters most is to separate code from what's not code and which doesn't follow the same rules: comments and string-like literals.

In my vim color scheme (https://github.com/Canop/patine) I only have three colors: one for code, one for comments, one for strings, and I find reading the code easier and less tiring this way.

[z5h]

Yes yes yes! For a long time this three color style was my philosophy. It's all you need.

I'm currently (with new laptop) doing a thing where I try to install/customize as little as possible. This means not using that philosophy, but not because it didn't work.

[mikelward]

Me too. Plus a color for errors, and one for line numbers and other non-code parts of the UI.

https://github.com/mikelward/conf/blob/master/vim/colors/bas...

And a similar theme I wrote for vscode.

https://marketplace.visualstudio.com/items?itemName=mikelwar...

[pixelmonkey]

I've watched a lot of talks on Python by @dabeaz (David Beazley) and attended a couple of his in-person courses in Chicago. I was always amazed about the fact that he used emacs with no syntax highlighting, no line numbers, etc. as his live coding buffer. When I asked him about it one time, his answer really made me think hard about my own "souped up" vim setup.

He said, "The hard part of coding in Python isn't getting the syntax right; the hard part is getting the logic right. Syntax highlighting makes me focus on the syntax when I should be focusing on the logic."

I didn't change my own setup, but it did get me to question my default assumptions on the practice.

That said, one specific example when syntax highlighting is very useful IMO is "rainbow parentheses". Especially when coding in Scheme, Racket, Lisp, Clojure, etc. But also for matching parens in fluent APIs and for matching braces in JSON.

[gav]

I spent a long time without syntax highlighting, or very minor highlighting (parenthesis/brackets/braces) but at a conference somebody told me that looking at monochrome text all day was depressing and that adding color with syntax highlighting made things less gloomy.

Since then I've liked adding a little color.

[CmdrKrool]

A counter response to Beazley's quote might be, "syntax highlighting helps the syntax get out of the way so that I can focus on the logic".

I suppose that's exactly what's happening in your "rainbow parentheses" case when you have way better things to do than squinting to count those little bleeders.

[twotwotwo]

The most intriguing version I've heard of this was also based on the feeling that it's already easy to scan for keywords and structure; they went a different direction, using color to make different things (especially confusable ones) look different: https://wordsandbuttons.online/lexical_differential_highligh...

I don't feel like I know how/if highlighting helps, so all I can really say is seems interesting.

I think some of the problems commenters are having with the color scheme are because the site has a dark mode and contrast might be worse when it's on. Maybe in that mode text colors meant for a dark background are still getting applied in the white-backgrounded code fragments.

[hzhou321]

It is not backward. The keywords to a program are like skeletons to a body and highways to a city. While we agree that the organs or even muscles are more meaningful to a body's function and the business inside buildings off the road are the essence of a city, skeletons and roads provide structures and makes it possible for those "meanings" to render. Without it, one can't practically dive into the more complex and meaningful stuff without getting lost. While the keywords are not the real meaningful part of code, it contributes the most to organize and to manage the complexity of code. So functionally, in terms of managing code and making writing and reading sophisticated programs possible, keywords are the most important parts.

[marktangotango]

I read this as the author advocating for some form of "comments first" development philosophy. As such, I'd like to submit this well known bit of work by Knuth for consideration (by anyone not already familiar with it):

https://en.wikipedia.org/wiki/Literate_programming

IME that gives all a starting point or base line for discussions around "what can more/good/better comments and support for documentation do for me".

[creatonez]

Of note is that Kate editor, when used with a language server, has an interesting approach to syntax highlighting. It has something called rainbow highlighting, which colors each variable/class/whatever uniquely.

[recursivecaveat]

I have also heard this called 'semantic highlighting' for anyone searching for a plugin for their editor. Not sure if any do this, but it would be interesting to try a version that assigns bands of colours to different types of symbols. Eg earthy colours for parameters, neon for locals, pastels for globals, etc.

[squeaky-clean]

You can enable this in PyCharm too (the IDE from the post) and probably every other IntelliJ variant. I believe it takes a hash of the variable name and turns it into a color? Because it will consistently keep color for the same tokens across projects and files. Really useful!

Though maybe I installed a plugin to do this, I'm away from ny laptop at the moment (happy holidays).

[jobigoud]

Interesting! Are the keywords also having their own color each, or are they grouped in a single color?

[MrPatan]

I think there's two ways people look at code: as text to be linearly read, or as a structure to be navigated visually.

I'm on the later camp, and I believe that's why I dislike the "movement" towards getting rid of puntctuation like (in JS land) semicolons, function braces and parens, and the like.

That helps me parse the code visually into its structure, while it must just appear like noise to somebody "reading" code linearly.

Now, for the kicker: Who do you think writes more blog posts about how much they like their languages and code highlighting, people in the "text thinking" camp, or the "visual thinking camp"?

[wruza]

Syntax highlighting is not enough to stand out sections and blocks either way. Few good ideas do exist (like #pragma mark + dropdown, etc), but it would be nice to see that in more languages and in greater usability.

  #.h1 Auxiliary functions
  #.h2 Date routines
  function foo(x) {
    #.summary {
      // this foo does
      // no bar, baz
    }
    #.fold {
      assert(x != null)
    }
  }

code-style.css:

  .summary > comment {
    font-size: 20px;
    color: red;
  }
  .fold {
    display: fold;
  }
  function-kw {...}
  function-name {...}
  .h1 {
    margin-top: 80px;
  }
  comment {
    margin-top: 5px;
    margin-left: 10px;
    border-left: 2px solid grey;
  }
  id[name=“assert”] {
    color: green;
  }

That’s what cascades stylesheets were done for. Another advantage is that we could create color themes with css, not with some cryptic barely documented config. And then toggle read/edit/toc like your wiki page. We could write entire technical documents in it.

Sadly, that’s not possible as current mainstream stuck in raw text. We have all formatting for pointless blah-blah, but no formatting for a thing that manages everything.

[beaconstudios]

this seems fundamentally similar to the idea of literate code, where the domain and context-specific information like comments (and in TFA, function and variable names) are put front and center.

This approach makes more sense to me though, as literate programming emphasises writing a book that incidentally contains source code, whereas the idea of valuable comments nowadays is closer to highlighting concerns or explaining functionality that isn't evident or easy to read in the code itself.

Or in other words; this sounds like a good idea! I wonder if it would help decrease the incidence of people ignoring and not updating comments though, as a developer's focus is often primarily on correcting the code and thus even with bolding the comments may end up falling into the same trap as banner blindness[1].

[1] https://en.wikipedia.org/wiki/Banner_blindness

[franciscop]

I totally agree, made a while ago a snippet for Atom with syntax highlighting based on a similar article [1] that will make comments bright pink (meta-tweet with the code in effect):

https://twitter.com/FPresencia/status/1133733608785473536

For copy/paste (in Atom -> Stylesheet...):

    .syntax--comment,
    .syntax--punctuation.syntax--definition.syntax--comment,
    .syntax--comment .syntax--markup.syntax--link {
      color: rgba(255, 51, 255, 0.8);
    }

    .syntax--comment.syntax--block,
    .syntax--comment.syntax--line {
      background: rgba(255, 51, 255, 0.1);
    }

[1] https://jameshfisher.com/2014/05/11/your-syntax-highlighter-...

[PretzelFisch]

It doesn't look like you completely agree, you kept the code blocks readable rather then flipping their styles like the author.

[klodolph]

Maybe for internal comments. I like having different styles for docstring comments and other comments.

    /** Frobnicate the weevil with the given ID and return 0 on success.
     *
     * Locks the weevil during frobnication, which may take a while.
     */
    int weevil_frobnicate(const char *id);

The most important part here is the function definition and its types and parameters. Usually, when I'm looking for a function, the name and type is enough to find what I'm looking for. So I want the function declaration to stand out and the docstring to be faded.

[czr]

for those interested, there's a longer discussion of this idea at https://jameshfisher.com/2014/05/11/your-syntax-highlighter-... (2014)