[HN Gopher] Getting syntax highlighting wrong
___________________________________________________________________
Getting syntax highlighting wrong
Author : robenkleene
Score : 156 points
Date : 2025-10-15 18:59 UTC (4 hours ago)
(HTM) web link (tonsky.me)
(TXT) w3m dump (tonsky.me)
| the__alchemist wrote:
| Needs examples of what a few common editors and IDEs use by
| default to make the case of what they do well and don't, at least
| in conjunction with the title. What does RustRover do well?
| Poorly? What about Github in-browser/ VsCode with its deafult
| Python config?
| floxy wrote:
| I thought we all agreed that Turbo Pascal/C had the best color
| scheme?
| AnimalMuppet wrote:
| No, _we_ didn 't agree on anything - especially if by "we" you
| mean "all of HN" or, worse, "all of software engineering".
| nailer wrote:
| Except tabs versus spaces, which ended back in 2021 we all
| decided the best indentation was the emoji corn.
| OhNoHereWeGo wrote:
| Those were the days!
| cek wrote:
| "In matters of taste, there can be no dispute." -dad
| bravetraveler wrote:
| "Challenge accepted." - Internet
| oofbey wrote:
| This isn't just a matter of taste. The colors exist to aid in
| the task of coding. How well they do that is measurable.
| peaseagee wrote:
| Sure, but how well they do that for each individual person
| is, well, individual...
| nailer wrote:
| Sure, but if you measure that for a ten thousand people
| (controversially, ten thousand people that aren't already
| programmers may be better) you can get a good idea of what
| is efficient and what isn't.
| ethanrutherford wrote:
| Maybe, but also maybe not. Ten thousand people giving ten
| thousand uncorrelated responses is also a possible, not
| unlikely result of such a test. There's also the question
| of whether or not your methodology for "measuring" what
| is effective and what isn't is even possible, let alone
| sufficient for a definitive conclusion.
| herpdyderp wrote:
| It's also pretty easy to take a theme you like and make tweaks. I
| have a local VS Code "extension" which is my custom color theme
| (never bothered to publish it).
| cyberax wrote:
| I like examples with more colors? For me, colors serve as a sort
| of a token highlighter. It's easy to see the different kinds of
| tokens.
| ricardobeat wrote:
| I get the impression you did not follow through with the whole
| article, as that is the point being made. In the colorful
| examples, variable declaration, access, parameters, method
| calls and event the mistyped return have similar colors, making
| the token types indistinguishable. There are also way too many
| colors to be able to recall anything.
|
| Removing color from variables is a bit too far for me though, I
| expect the declaration and any subsequent access to be visually
| consistent.
| t-writescode wrote:
| I'm the same way. The squiggly lines would tell me if `return`
| is spelled wrong more than a slightly off color would.
|
| But colors help me separate "this whole thing is a string" from
| "this is a string but with code inside it". Comments being gray
| doesn't make them less visible for me, just visibly different
| which is all I'm looking for.
|
| 99% of the colors don't actually matter to me. It's the
| distinguishing of conceptual elements that are adjacent to each
| other that matters more to me.
| freetonik wrote:
| Related (from recent posts on HN):
| https://ruudvanasseldonk.com/2025/abstraction-not-syntax
|
| I really like the idea of color representing scope and
| relatedness, rather than syntax.
| pavlov wrote:
| My most unpopular opinion about syntax highlighting is that
| comments should be displayed in a proportional serif font.
|
| (And of course white background always. Dark mode is depressing.)
| arnsholt wrote:
| After a couple of years working in Smalltalk, I've acquired the
| hot take that _all_ the code should be in a proportional font.
| Admittedly it doesn't work quite as well for brace syntax
| languages, but in Smalltalk and Python it's great.
| wizzwizz4 wrote:
| It works better if you're using Elastic Tabstops.
| t-writescode wrote:
| I'd be good with a hot-swap between markdown and not-markdown
| for comments, too, honestly.
| bluGill wrote:
| Every once in a while I'm building a table in comments and then
| spacing matters. Most of the time I don't care.
| nonethewiser wrote:
| Your preference for light and dark mode doesnt change with the
| ambient light?
|
| Im always surprised by the number of people who will delcare
| one absolutely better than the other without consideration for
| this factor. Sure, people have some general preferences, but I
| thnk it's 90% about the ambient light.
|
| If it's pitch black most people will prefer dark and if it's
| bright daylight people will prefer light.
| skirmish wrote:
| F.lux / Redshift / Gammastep exist. On sunset, my screen
| becomes much darker and tinted yellowish / reddish. Then
| white backgrounds look fine, and I happily continue using my
| light color themes late into the night. Also, bias lighting
| on the wall behind the monitor helps my eyes avoid strain.
| brycewray wrote:
| > (And of course white background always. Dark mode is
| depressing.)
|
| Twice during the last couple of years, I've done this poll
| online: When reading a code block in your
| chosen viewing mode (light or dark), which of these
| should the code block always do? - Match my chosen
| mode - Have a dark background - Have a light
| background
|
| ... and, each time, "Match my chosen mode" won with well over
| 75% of the votes (about 150-200 total votes in each case).
| Accordingly, I've styled my site's code blocks to handle both
| dark- and light-mode viewing. I also provide a switch that
| enables one to toggle back and forth just in case the chosen
| system mode doesn't match how one wants to view code blocks (
| _e.g._ , some people _prefer_ to see code blocks in dark mode
| even if they're otherwise using light mode).
| hansvm wrote:
| The brain picks up on remarkably subtle things, especially when
| you can leverage its huge pattern recognition cores. I like the
| argument for having less clutter by default (i.e., prioritizing
| certain kinds of patterns over others), but it's been less than
| 40 minutes since an obscure syntactic highlighting based on the
| type of a variable saved me easily 30 seconds of debugging. It
| was immediately obviously wrong and immediately fixable. And I'm
| colorblind. I think you're able to use more colors effectively
| than the author gives you credit for.
| ethanrutherford wrote:
| hard disagree
| munificent wrote:
| It is hard to take color advice from someone who thinks it's a
| good idea for their blog to be black on intense yellow, with code
| samples light on black background.
|
| I'm not being facetious. The author is trying to show comparisons
| to the reader of various syntax highlighting schemes, but any
| difference between them is overwhelmed by the massive contrast
| between the bright yellow background and the black background of
| the code samples.
| smlavine wrote:
| I think it's fine. Better than purple on dark-grey that I've
| seen posted here.
| dysoco wrote:
| I think it's fine and it's certainly very recognizable
| hn_acc1 wrote:
| Dang, that was hard on the eyes..
| morshu9001 wrote:
| I agree with the advice but yeah, this website burned my eyes
| laktak wrote:
| yellow? had to go back to check - Try Darkreader :)
| ash_091 wrote:
| Agreed, I had to check a couple of other pages on his site to
| make sure it wasn't ironically done for just that particular
| post.
| bitexploder wrote:
| I immediately stopped reading when I saw the yellow. I like
| colors. I like rainbow delimiters. I will not change at this
| point. I am okay with minimalistic highlighting. Used to use
| visual studio with more minimalistic highlighting, and that was
| fine too. It is a preference and I don't think it is worth
| indexing much on. If it bothers you, change it until it
| doesn't. I don't think about it much.
| Svoka wrote:
| I know. This is literally the ugliest page I saw this year.
| Bright background, bunch of ugly signs in header, text just
| gaslighting you about some shit.
| laristine wrote:
| > Here's a quick test. Try to find the function definition here
|
| It's funny that in the first example where the author asked the
| viewers to find the function definition, I was able to do so
| faster with the colorful syntax highlighting he considered wrong.
|
| To recognize different elements of code is more than just colors,
| but actual syntaxes of the language and the general shapes of
| code blocks.
|
| It's a matter of taste, and in my decades of programming, I've
| found colleagues and many teams trying for all kinds of fancy
| themes only to come back with a "boring" one, like Material
| Theme, which is also my main driver nowadays.
|
| I think the author had some good ideas, particularly around
| literals (what he called constants), rejection of the requirement
| for equal brightness, and emphasizing comments. The author is
| more than welcome to bring his version of perfect syntax
| highlighting to the market of ideas. Its adoption should prove it
| if his idea wins.
| tagraves wrote:
| I had the same experience -- it was way easier for me to find
| it with the rainbow highlighting (even though I already knew
| where to look when it came to the monochrome highlighting!).
|
| The author later asks what color class definitions were. I
| think this fundamentally gets wrong how syntax highlighting
| helps humans. I don't have a clue what color anything is in my
| favored highlighting, but my brain does incredible pattern
| recognition to help me digest code in it without me consciously
| knowing what color does what.
|
| So his arguments for why there's a problem don't hold up, but
| that doesn't mean there is not in fact a problem.
| thewebguyd wrote:
| Yeah I certainly dont' pay attention to or remember what
| color means what.
|
| I am however in that weird minority that prefers light
| themes, and I do also prefer minimal syntax highlighting. The
| author does have a point to an extent, but I don't think
| there's any one objectively better way to do it I think it's
| all personal preference.
|
| I don't like the rainbow highlighting, too distracting for
| me, and doesn't work particularly well with light themes. I
| did try the author's alabaster theme in VSCode though and it
| highlights the wrong things for me.
|
| (In C#) if I have var result = await SomeMethodName(param,
| param, param); It put both "result" and "SomeMethodName" in
| blue, the rest being black. I'd actually prefer it the other
| way around, highlight the programming language's keywords
| (var and await in this case) and leave my own names (result
| and SomeMethodName) unhighlighted.
|
| The theme was also inconsistent. The post says we shouldn't
| highlight PL keywords, but the proposed theme does highlight
| some keywords while ignoring others.
| Neywiny wrote:
| This is like, it might've been a Veritasium video? There was
| some YouTube video that started with a test, and the rest was
| predicted on one outcome but myself and most of the audience
| had a different one. At worst just read the code normally, at
| best you can jump to specific colors
| jchw wrote:
| I agree. I was baffled when I realized I was supposed to
| struggle with that example.
|
| I do agree that it is harder to see the return misspelling with
| the more detailed syntax highlighting, but when I'm coding I'm
| mainly focused on the actual tokens I'm writing, and you better
| believe I pick up on if the syntax highlighting is showing my
| token as wrongly being a keyword rather than an identifier, or
| the wrong type of identifier. Even if I don't actually know
| what the colors are, it will _look_ wrong.
|
| Rainbow vomit syntax highlighting logically seems like a bad
| idea, but like many things, even though it's hard to prove that
| it's better, I think a lot of people will agree that it really
| _is_ better. Especially with tree-sitter and LSPs giving more
| detailed syntax highlighting; I can feel the benefits of 'oh,
| that's the wrong identifier color, isn't it?' to the point
| where if I run into an edge case that breaks highlighting it
| becomes immediately noticeable.
| wijwp wrote:
| I wonder if OP has some kind of color blindness that makes his
| examples make more sense?
|
| I am able to parse the status quo example way better than his
| ideas.
|
| My theory is helped by his use of a yellow background on black
| text, which is horrific to read.
| btown wrote:
| To this point, I wonder if we can go even further in the
| direction "it's fine to have a 'zoo' of colors on the screen...
| as long as we're able to rapidly scan for patterns based on the
| _shapes_ of code and _relative positions_ of those colors. "
|
| Many games (especially gacha games where one may be tracking
| multiple orthogonal "levels" on any given piece of inventory)
| compress tremendous amounts of data into a character or gear
| item portrait; ticks on the top, dots on the side, colored
| frames, etc. - all so we can pick things out in a crowd without
| needing to set a custom sort order.
|
| And yet our IDEs, citing silly things like "render
| optimizations" and "consistency with ANSI escape codes," allow
| each character to have just a single foreground color, a single
| background color, and maybe a squiggly underline. Why stop
| there?
|
| Give me the freedom to add arbitrary overlays and decorations
| on any given token. Give me <ruby>-style elements [0] that will
| let me put a little colored dot or emoji at the top right of
| any token that meets a certain requirement... say, a utility
| function, or a reference from the file that's open at the top
| right of my screen.
|
| Let us swim in rainbows with sparkles flying past our eyes.
| We're strong swimmers.
|
| [0] https://developer.mozilla.org/en-
| US/docs/Web/HTML/Reference/...
| surgical_fire wrote:
| > It's funny that in the first example where the author asked
| the viewers to find the function definition, I was able to do
| so faster with the colorful syntax highlighting he considered
| wrong.
|
| Same. It sort of killed the article for me. I also thought that
| in his resulting theme the limitation of colors would
| eventually trip me up. Having numbers and strings be the same
| color is terrible - I have noticed mistakes in the oast where
| numbers were erroneously attributed as strings for being
| enclosed in quotation marks precisely because my theme gives
| those different colors.
| nikisweeting wrote:
| I must have a very different brain shape than the author. Color
| processing is for me subconcious, I don't get the "color
| overload" situation at all because my brain has hardware
| accelerated it long ago, there is no concious load to track
| additional colors or pick out differences. The only time I
| experience that is when looking at someone else's color scheme
| when pairing.
|
| It lost me after this part:
|
| > Here's a quick test. Try to find the function definition here:
|
| I found them instantly with more color, and struggled with less,
| and found the same for all the subsequent examples as well.
| mrits wrote:
| It just seems like some people prefer highlighting in the
| literal traditional sense while others like the more common
| color coordinated code.
| surgical_fire wrote:
| > Color processing is for me subconcious, I don't get the
| "color overload"
|
| Same. I noticed this on a Whatsapp group I have with old
| friends. About 8 people, so each gets a specific color in their
| name, and that's how I identify who is talking on a glance.
|
| Once one of them switched thier phone number, and had to leave
| and reenter the group. This caused the colors of everyone to
| change.
|
| For a couple of weeks it was hell. I was used to Person A to be
| pink, Person B to be yellow and so forth. I would reply to A
| thinking I was replying to B because their color changed, which
| caused a lot of confusion.
| zamadatix wrote:
| I actually found most of the more colorful examples easier to
| work with, though I'd probably prefer something more middle-
| ground the most. That may just be because I use Sublime most of
| the time and it's more middle-ground itself.
|
| It seems like the author gets most of their value from
| associating the specific highlight color with a specific meaning.
| I think I get most of the my value from the different highlight
| groups. From that perspective, I don't really care if I open an
| editor and strings are green - I care strings form one group
| that's different than variable names or etc. The main problem I
| had with the "complicated" scheme was the reuse of purple:
| branching, looping, imports, functions, this, new - these are not
| at all related so making them purple doesn't help me (or the
| author), regardless of total color count.
|
| I don't think either way is wrong, but it may feel like it to
| different people.
| merelysounds wrote:
| > If everything is highlighted, nothing is highlighted.
|
| Somewhat related, I got used to turning off syntax highlighting
| for some coding sessions.
|
| It started when I was using vim to edit large data files and
| syntax highlighting there was buggy.
|
| Later, I worked with large react files, where with each JSX block
| the latency and highlighting reliability was getting worse. So I
| turned it off too and I was surprised that I didn't see a big
| difference in readability after that.
|
| I'd still use syntax highlighting for backend work. But I don't
| mind looking at large html files or react prototypes sans
| highlighting.
| YuukiRey wrote:
| This is a really insightful post. I created a Vim color scheme
| that uses even fewer colors than his but I didn't realize that
| you might want to express nesting through varying lightness
| levels. I also didn't realize that using HSLuv and making all
| lightness uniform might actually hurt the scheme.
| modeless wrote:
| I thought this was going to be about highlighting based on symbol
| type or identity instead of language syntax, like all instances
| of the same type or function or variable would be the same unique
| color. I think I saw a vscode extension for that a long time ago,
| does anyone use it?
| avdwrks wrote:
| I agree that certain schemes overdo it with highlighting, but I
| disagree with his statements that things like function calls and
| keywords shouldn't be highlighted. Basically, if everything is
| important then nothing is; but I still want my code to be easily
| scannable. Right now I'm using using a version of Solarized that
| uses the default VSCode syntax highlighting and it's been pretty
| great.
| whatshisface wrote:
| Here's an idea that hopefully will inspire something. You could
| use major color differences for large semantic differences
| (numeric literal vs. comment), midrange color differences for
| intermediate semantic differences (function call vs. local
| variable) and small color differences for small semantic
| differences (local variable vs. class member).
| reissbaker wrote:
| I've tried variations on low-color syntax highlighting (I've even
| tried no syntax highlighting!). While I agree most color schemes
| are _too_ colorful, to the point where it 's largely noise, I
| think trying to go super low on colors ends up hurting
| readability.
|
| For example: keywords, specifically, are actually very useful to
| highlight. This post complains that misspelling "return" didn't
| make easily-scannable color changes (it changed the color from
| purple to red, which still looks like a special color)... But
| then, proposes to not highlight keywords at all, so misspelling
| "return" would still be impossible to quickly scan for visually!
| In both cases with the proposed color scheme, "return" and
| "retunr" would have identical coloring: white.
|
| Generally speaking I think a lot of the visual noise of syntax
| highlighting comes from having _too many_ colors. For example,
| you don 't need the "class" keyword to have a different color
| than the "const" keyword -- and many syntax highlighting themes
| are guilty of doing exactly that. But it's useful to be able to
| immediately, visually see if you made a typo: if you expected to
| write a keyword, and it's colored like normal text, you know you
| messed up. Similarly, it's useful when reviewing code to quickly
| be able to tell whether there's a typo somewhere.
|
| I have a pretty custom syntax highlighting theme for Neovim. I
| have a few categories that are highlighted differently:
|
| - Keywords
|
| - Function calls and method calls (highlighted identically)
|
| - Property accesses (to highlight mistakes when you're simply
| accessing a property instead of calling it -- it's a different
| color than a method call)
|
| - Non-string built-in primitive types like numbers, booleans, etc
|
| - Strings
|
| - Comments
|
| - Types
|
| Ultimately I think syntax highlighting is a tool to let you see
| mistakes. If you go too wild with the colors, it's true that
| since everything is a unique color, it's hard to tell when
| something is the wrong unique color. But you can use a relatively
| restrained palette and get a lot of value, and I think this post
| goes a bit too far in terms of reducing color usage.
| SoftTalker wrote:
| I learned to code back when there was no syntax highlighting.
| You had one face, one font, one color on your 80x25 terminal.
| It might have been green, or amber, or white(ish) but that was
| it.
|
| I'd prefer minimal-to-no syntax highlighting except for things
| that should NOT be there. Nonexisting keywords should be
| highlighted. Unclosed strings. Unbalanced parens or brackets.
|
| I like making comments their own color so you can easily
| separate them from actual code but I'm otherwise in the minimal
| camp.
| ziml77 wrote:
| Your thoughts seem similar to mine. Going overboard with the
| colors just turns it all into visual noise. But cutting down as
| far as they have removes useful colors.
|
| I've always thought the default Visual Studio color scheme was
| a nice balance. And I especially like the green comment color
| in that theme. It doesn't scream for your attention but also
| doesn't fade into the background (which, annoyingly, many
| themes do quite literally).
|
| Of course if the author prefers their extra minimal colors I'm
| not going to tell them they're wrong. Though framing it as
| objectively better I do disagree with.
| thewebguyd wrote:
| > But then, proposes to not highlight keywords at all, so
| misspelling "return" would still be impossible to quickly scan
| for visually!
|
| Yeah I generally want the opposite. I want keywords to be the
| thing being highlighted.
|
| I also really dislike overly colorful themes, and I prefer
| light mode (dark mode is far too hard on my eyes, oddly enough
| I have to strain to focus or it's fuzzy).
|
| But the author's alabaster theme still highlights the wrong
| things and is inconsistent.
|
| public async Task<byte[]> SomeMethodName(Type param, Type
| param) results in Task, SomeMethodName, and BOTh the data type
| and parameter name being highlighted.
|
| If highlighting isn't for keywords, why is Task and the data
| types highlighted?
|
| likewise var result = await SomeMethodName(param, param); has
| result and SomeMethodName highlighted and I generally want the
| opposite, I want the PL's keywords highlighted and nothing
| else.
| tasuki wrote:
| > prefer light mode
|
| I prefer dark mode (precisely for the garish colors, sorry),
| but been using light mode... because it's hard to make
| everything use dark mode!
|
| When my terminal was dark, the eg some docs in the browser
| were light, switching back and forth was quite painful. Yes,
| it's super simple for websites to detect the preferred color
| scheme with @media (prefers-color-scheme: dark) {}, yet most
| (such as this one) don't. I could use some hacks, but then
| I'm in for a world of pain. So I just use light theme
| everywhere and it's ok(ish).
| take-five wrote:
| I mostly agree with the author - Christmas tree is a mess. But I
| also think the final theme was too minimalistic. I find it
| incredibly helpful when language keywords like "try", "await", or
| "new" are highlighted.
| IshKebab wrote:
| I agree. Not even highlighting keywords is silly. The overly
| colourful example he gave is bad, but his alternative is bad in
| the opposite direction. Middle ground is where it's at.
| plorkyeran wrote:
| > Sometimes it gets so bad one can't see the base text color:
| everything is highlighted. What's the base text color here?
|
| I don't understand the premise of this. What is "the base text
| color" and why would it be important to be able to see it?
| Everything is assigned some specific color and I don't understand
| why one of the colors would be considered more important than the
| others.
|
| > Here's a quick test. Try to find the function definition here:
| [...] See what I mean?
|
| No, I don't. From the context I can figure out that the author is
| arguing that they're easier to find in the second example, but I
| found it easier with the first. They're both what I would
| consider pretty bad syntax highlighting schemes, though.
| joe5150 wrote:
| I don't get this either. My code doesn't have "base
| text"...everything is something! I can see that not being the
| case for something like HTML, but not for most programming
| languages.
| ferd wrote:
| No... the best way is to use the same color for all occurrences
| of the same identifier. So, on the last example, all instances of
| say "audio" should be of the same color, and those of "filename"
| of another color.
|
| Original idea from here: https://medium.com/@evnbr/coding-in-
| color-3a6db2743a1e
|
| One impl for Emacs: https://github.com/ankurdave/color-
| identifiers-mode
|
| I still admire you Niki.
| IshKebab wrote:
| I tried that for a while but found it's just too colourful. I
| prefer _tasteful_ colours, somewhere between the two bad
| extremes demonstrated in this article, but also when you click
| and identifier it highlights all instances of it.
| runxel wrote:
| And yet here we are in VSCode, still completely unhinged, not
| letting us have background colors in themes at all.
|
| Apparently it's too technically complex :D (their words in the
| open GH issue, not mine)
| morshu9001 wrote:
| Vim already does it the way the article says is right, by
| default.
| vrnvu wrote:
| I've been using a "no syntax highlight" theme for years. I
| recommend it. After a while, your brain basically turns into an
| AST parser and code becomes easier to read.
| webdevver wrote:
| my favourite has always been Visual C++ 2005, with very simple
| rules:
|
| - blue for keywords and integer constants
|
| - red for strings and characters
|
| - green for comments
|
| - black for everything else
| css wrote:
| I love the concept of lexical differential highlighting [0]
| (discussed here [1]). It makes reading math so much easier,
| especially in dense code. However I don't know of any editor that
| implements a feature like this.
|
| If you paste the following code into the example block in [0] you
| can see how useful this can be: while (b -
| a).abs() > EPSILON { let c = a + (a - b) * f_a / (f_b
| - f_a); let f_c = J(c); if f_c * f_b ==
| 0.0 { a = b; f_a = f_b;
| } else { f_a /= 2.0; } b
| = c; f_b = f_c; }
|
| [0]:
| https://wordsandbuttons.online/lexical_differential_highligh...
|
| [1]: https://news.ycombinator.com/item?id=20414528
| louthy wrote:
| If you're not using Monokai classic then you're definitely
| getting syntax highlighting wrong
| aftergibson wrote:
| I guess I'm one of the color-loving fools, but I found the "look
| how bad it is" examples far easier to read than the alterative.
| frenchie4111 wrote:
| In my experience I have never once thought about what color means
| what, but if the colors are wrong I can "sense" that something is
| broken. It almost becomes a second sense, the patterns are
| recognized somewhere deep in my mammal brain
| bsimpson wrote:
| You might not skim for `retrun`, but if you're used to it
| turning purple when you type and it doesn't that time, you
| might notice.
| uncletaco wrote:
| I have used Tao theme in Emacs along with rainbow identifiers for
| over a decade now (on light mode) and I personally prefer a less
| colorful palette on my text editor. Makes a nice contrast with my
| eboy tokyo/San Francisco backgrounds which I also love dearly.
| WalterBright wrote:
| My scheme is a bit modest. Comments, keywords, and string
| literals are highlighted. The rest is just black on white. I tend
| to agree that less is more.
| sebastianconcpt wrote:
| Good point.
|
| If is not highlighting structure then is failing to do the pre-
| optimization that helps your organic parser do that.
|
| The "matter of taste" part can come _after_ the "matter of
| structure" was adequately elevating the right categories of
| elements to each level, hence inviting to receive the required
| attention.
| zarzavat wrote:
| The diagnosis is valid but the prescription is incorrect.
|
| The solution is not to use fewer colors, but rather to take
| advantage of the 3D space of color perception.
|
| Good themes have a hierarchy. Perhaps red is for keywords and
| blue is for symbols, but different kinds of symbols have
| different _shades_ of blue. A lighter blue for functions, a
| darker blue for classes, for example.
|
| This allows the highlighting to convey a higher amount of
| information when reading code closely, without causing
| distraction when skimming through code.
| cvoss wrote:
| > Please, please don't highlight language keywords.
|
| Agreed with almost everything the author had to say, but not
| this. Hard disagree. In my view, keywords are the single most
| important thing to highlight. I'd be ok without anything else.
| Keywords sketch the structure of the program in most languages.
| The thing I want my eye drawn to, in the case of top-level
| definitions, for example, is the keyword. It's the predictable
| anchor as I'm scanning a long series of definitions. The
| identifiers are not: some are long, some are (very) short.
|
| And how do I understand the control flow of my program? I look at
| keywords. If I want to read the condition, I have to find the
| condition. But all the conditions look different. What's the
| reliable way to spot them? The predictable 'if' that precedes
| each one, without fail.
|
| My eye is a parser. It needs to recognize tokens. But some tokens
| are easy to confuse: keywords look just like identifiers.
| battesonb wrote:
| Agreed on this. Especially with the return keyword argument
| presented in the same article.
|
| An assertion of correctness relating to a matter of taste is,
| ironically, going to be trivially falsifiable. Even though I
| found myself personally agreeing with most of what the author
| had to say (for my tastes)! I definitely want to try lifting
| the visual importance of comments.
| m463 wrote:
| I kind of agree, but I think it might be ok to turn off
| keywords sometimes, unless broken. Highlight "retunr" in
| reverse video.
| frou_dh wrote:
| I like having the identifiers of function/method _calls_ being a
| distinguishable colour, because when looking at an overall
| section of code, they are the 'wormholes' to other code, and so
| one of the most useful things to be able to pick out instantly at
| a glance.
|
| But I agree with the author that if little to nothing ends up
| being given the base text colour (e.g. white or black) then the
| design is an unthinking one (less of a design process, more of a
| box-ticking exercise to assign a unique colour to everything that
| can possibly have one).
| jasonjmcghee wrote:
| > Can you see it? I misspelled return for retunr and its color
| switched from red to purple.
|
| That's not what syntax highlighting is for though.
|
| That's falls under diagnostics. A big red squiggly line. The
| honest test would be to add that in both cases.
| ajanuary wrote:
| They're not talking about the squiggly line. The word
| return/retunr gets highlighted in slightly different colors
| based on whether the highlighter is picking it up as a keyword
| or a variable name, but in the scheme the colors are similar.
| jasonjmcghee wrote:
| But their argument is based on the underlying assumption that
| it's the responsibility of the syntax highlighter to tell you
| when you've made a typo.
|
| I am presenting an argument against this - and stating it's
| the responsibility of _diagnostics_ to tell you when you've
| made a typo, not syntax highlighting.
| renewiltord wrote:
| In my experience low-color guys were either uber-programmer
| greybeards or fucking morons cargo-culting uber-programmer
| greybeards. Most bimodal property ever. You don't find that with
| vim bindings etc.
|
| I wonder which software engineer traits are like this. Maybe
| everything that it's kind of low-friction to do. If you had a CRT
| screen you're probably a details oriented person. If you've got
| conky running you're from the time when you needed to watch those
| things _or_ you 're a moron cargo culting that.
| jmull wrote:
| I don't think the value is for some things to stand out and other
| things to fade back.
|
| It's for color to label the type (or other high-level semantic
| characteristic) of different tokens.
|
| > What's the base text color here
|
| Why should there be a "base text color" at all?
| drc500free wrote:
| I seem to be the only person here who prefers the author's
| approach!
|
| The combination of adhd and colorblindness seems to make most
| multicolor displays just visual snow to me. It's like looking at
| one of those magic eye pictures. I struggle with
| foreground/background in both vision and hearing, and it took
| quite a long time to realize others don't process like that.
| ayhanfuat wrote:
| > Here's a quick test. Try to find the function definition here
|
| This is only an issue for websites and they generally have short
| code snippets anyway. I've been using the same theme in my editor
| for the last 10 years so it is much more useful there.
| rbongers wrote:
| Keywords should definitely be highlighted. It's part of the
| structure of the code. Being highlighted makes it very quick to
| distinguish between keywords and variables and helps readability
| by making them easier to skim over and jump to. Maybe they could
| be the same color as punctuation, if number of colors is a
| problem.
| thewebguyd wrote:
| Agree.
|
| I also like minimal themes (and light mode!) but keywords are
| precicesly the thing I want highlighted. The "Visual
| Studio(Light)" theme in VSCode gets it pretty close to what I
| want but still has some inconsitencies that bug me but I
| haven't bothered making my own to fix them yet. It primarily
| just highlights keywords, comments, strings.
|
| But then you can have something like public async Task<byte[]>
| SomeMethod(DateTime date, int someNumber) and int is
| highlighted but DateTime isn't...
| dlvhdr wrote:
| The white color literally has the best contrast on the dark theme
| and for me stands out the most. So this achieved the opposite
| (for me)
| ethanrutherford wrote:
| 1. I find it pretty suspect you intentionally don't use the
| default syntax highlighting in vscode, the editor you're using,
| as your baseline. Many of your comments just wouldn't hold nearly
| as much water if you did.
|
| 2. having keywords vs variable names vs functions be different
| colors _helps_ you find misspellings, not the other way around.
| But that 's almost beside the point, because it's your
| linter/intellisense/error checker's job to let you know when you
| have an obvious syntax error. You're also taking this as if
| you've just discovered this code block in the ether and have to
| debug it, rather that the reality that if you had actually been
| the author, you would have immediately noticed it, even without
| red squiggles, because it would be immediately obvious when you
| type it that it doesn't highlight as a keyword. Human brains are
| hardwired for pattern recognition, one could even argue it's the
| only thing the human brain is even good at.
|
| 3. I'm not sure where the notion of comments being grey is
| "tradition", but in practically every editor I've used, the
| default color for comments is a pretty easy to pick out green.
| Comments usually stick out like a sore thumb, in fact, as they
| typically don't share their color with any other syntax. Again,
| this points to you specifically picking out a non-default theme
| to make your points against.
|
| 4. "... gets so bad you can't see the base color" this isn't so
| much a thing, rather, the base color just _isn 't white_. Which
| is because most people would agree that pure white on black is
| not pleasant to look at for long periods of time. There's a
| reason you don't see many dark mode highlighters use white.
| Again, default for vscode is a pleasant light blue. Plenty of
| contrast, but not so harsh it strains your eyes.
|
| 5. This is the most psychological, and subjective one, but plain,
| unhighlighted text just doesn't _look_ like code. It looks like
| plaintext. Because plaintext is unstructured. Syntax highlighting
| brings out (highlights) the inherent structure of code. And that
| 's kind of the entire point; it's there to show the structure. It
| may help you spot a typo, but that's not why it's there. That's
| an incidental perk. It's there because our brains are really good
| at pattern recognition, and having syntax follow a predictable
| color scheme taps in to that pattern recognition.
| ash_091 wrote:
| > Close your eyes (not yet! Finish this sentence first) and try
| to remember what color your color theme uses for class names? Can
| you? If the answer for both questions is "no", then your color
| theme is not functional.
|
| I'm sure this varies person-to-person, but for me at least this
| is not a good test.
|
| I couldn't list the notes in Clair De Lun, but I'd certainly
| notice if I heard the wrong note played. In much the same way, I
| have no idea what color classes are in my theme, but I certainly
| notice when it's wrong.
| PrivateButts wrote:
| To each their own. If anything I tend to go farther, like using
| different tints for async vs sync functions in python and
| gdscript.
|
| What'd be nice would be easier customization of these rules in
| your ide, like quick email rule creation in Outlook. Select what
| you want to alter, the rule modal shows you a couple options for
| targeting, then you can apply whatever highlighting you want.
| jraph wrote:
| Like many comments here, I disagree with this article.
|
| Notably, I don't necessarily remember which colors are used by my
| code editors off the top of my head, but you can be damn sure
| that if the smallest thing is different tomorrow, I will notice,
| and if anything is the wrong color, I will immediately notice
| something is wrong. Put as many colors as possible and it makes
| it easier for me to spot any mistake. Although I can understand
| that more than a few colors can be distracting to some people.
|
| As for "everyone does it wrong", and in particular wtt the
| Christmas tree effect, I find Kate's and IDEA's default color
| themes quite well designed and balanced, and where each sub
| expression start and end.
|
| I do find light themes far more readable, and only use dark
| themes under very bad lighting conditions where a white
| background would hurt the eyes even at minimal screen brightness.
|
| Bonus topic: in the Christmas tree screenshots, you can notice
| that parentheses are of different colors. This creates a visual
| mess but I do activate this option in Kate anyway because it is
| very useful to quickly check that the parentheses are balanc
|
| It's less necessary when you have syntax checking though, because
| the editor will put a red background or draw squiggles.
| ash_091 wrote:
| Are we sure this guy isn't trolling us? The advice about theming
| while using a yellow-on-black blog format, the "dark mode" toggle
| which makes the whole page black except for a spotlight focused
| on the mouse cursor... I'm not sure.
| NoSalt wrote:
| I like the dark color-scheme because the light color-schemes look
| like a lighthouse has been built on my desktop; it is an affront
| to my senses and burns my eyeballs.
|
| I have no idea where I got it, but I have a quick JavaScript
| bookmarklet that darkens any page for me in an instant. I love
| it. And I, unfortunately, have to use it every time here on
| Hacker News.
|
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| - - - - - - -
|
| javascript: (()=>{var e="quick-and-dirty-dark-theme",d=document,i
| =d.getElementById(e);if(i)d.body.removeChild(i);else{var
| r=d.createElement("style");r.id=e,r.innerHTML="html, img, video,
| iframe { background:
| #fff;%20filter:%20invert(0.9)%20}%22,d.body.appendChild(r)}})();
| Garlef wrote:
| Interesting post.
|
| Just like everyone else, I disagree on some aspects.
|
| One has not been brought up. So here's goes:
|
| My first reaction to the highlighting of the literals (strings,
| numbers, etc) was:
|
| "This is wrong! Who cares about the exact value here? I want to
| understand the program flow!"
|
| But thinking about it a bit more, this is actually a deficiency
| in the code itself, not the highlighting:
|
| It's magic numbers! And they get highlighted for you.
| ninjaranter wrote:
| Agree with the premise, but I built a theme with a different
| interpretation:
| https://marketplace.visualstudio.com/items?itemName=narenran...
|
| The primary difference is that my theme has an underlying
| assumption that colors have semantic meaning that we all
| implicitly understand(red = bad, yellows/oranges are action-
| oriented etc). So instead of color = syntax, my theme
| semantically maps color = intent.
|
| * Warm colors (orange/red) for actions -- throw, return, await.
|
| * Cool colors (blue/green) for definitions and values -- function
| names, constants, variables.
|
| * Muted neutrals for structure and noise -- punctuation, keywords
| like var or const
|
| This means comments are muted, contrary to the author's proposal
| - imo while they are important and helpful, they're secondary to
| the actual code
|
| My primary design goal was that if you open a large file and
| squint at it, the flow should be immediately obvious (the flow
| colors stand out, if you see a bunch of blues it's calling a
| bunch of other functions etc)
|
| (You can see screenshots in the link)
| andness wrote:
| I recently switched from PyCharm to VSCode and the feature I miss
| the most is the bold yellow highlight of the symbol under the
| caret that was the only custom config I had in PyCharm. VSCode
| only allows a weak <<box>> around it which I struggle to see when
| scanning code quickly and I haven't managed to find a good
| solution.
| battesonb wrote:
| I'm surprised not to see any comments about rainbow brackets for
| the Lisp family of languages. I just started in a non-Emacs
| environment to avoid learning two things, but colourful brackets
| have made the paradigm shift a lot easier for me.
| moribvndvs wrote:
| Another "everyone's doing this highly subjective thing wrong"
| post. Why do you think there are so many color schemes, my guy?
| Pick the one that works for you and move along.
| rascul wrote:
| I agree with the over highlighted examples being over highlighted
| but the author's preferred schemes are even worse, especially
| with different background colors. I guess everyone has their own
| opinion and thankfully there are plenty of options.
| 1718627440 wrote:
| > Most languages don't distinguish between those, so there's not
| much you can do syntax-wise. Sometimes there's a convention (e.g.
| -- vs /* */ in SQL), then use it!
|
| I do this in C to: /* */ for explanation, // for temporary
| disabled.
| tmtvl wrote:
| > _There 's no [...]_ good-looking _" dark teal"._
|
| > _light [themes] can 't look good. Science_
|
| Sorry, but 'my preference is x. Therefore y. Science' is not how
| any of this works. I get that it's a joke, but considering light
| themes are objectively superior (c. ref. <https://journals.sagepu
| b.com/doi/abs/10.1177/154193121360181...>), I take umbrage.
| deepsun wrote:
| I'd say way more damage occurs when people neglect warnings and
| errors.
|
| Like literally IDE not just highlights, it underscores a problem
| in red/yellow, puts a marker on the left of line, and on the
| right at the scrollbar as well. Also marks the whole file tab and
| file name on project tree. Gives a warning when user creates a
| commit.
|
| Still, many, too many programmers don't care to either fix or
| silence it.
| juancn wrote:
| The most important thing is familiarity.
|
| I mean, any of those would work, but the one that works best is
| the one you're used to.
|
| The brain is great at learning patterns, I'm extremely used to
| IntelliJ's classic theme (light) with Firacode with ligatures.
|
| But that's me, I've been daily driving that for years, so stuff
| just pops up at me.
|
| I like semantic highlights (i.e. something is static or a field,
| or whatever) rather than pure syntactic ones, but what matters
| most to me is stability.
|
| If it changes for no reason, it's jarring and takes a while to
| get used to it again.
| yaro330 wrote:
| Author finds out they're colour blind.
| amanzi wrote:
| I was prepared to hate this article based on the clickbaity
| headline "...everyone is getting syntax highlighting wrong". But
| I agree with the premise, and I find his proposed scheme a lot
| better than some of the most popular colour schemes that I see
| online.
|
| But I use the Nord colour scheme in VS Code, and it appears to
| follow the same principles as what the author proposes. There are
| only a few colours, with a lot of the code remaining in the base
| colour. Also, Python comments starting with `#` are dimmed, but
| comments in triple-quote blocks are highlighted. The funny thing
| is that I had never even noticed this, it just seemed to be
| intuitive.
___________________________________________________________________
(page generated 2025-10-15 23:02 UTC)