1. 11
  1. 19

    Not a big fan of that image of real lit using syntax highlighting. In programming, we use tons of repeated elements like braces, colons and keywords like for, while, if, import, and hundreds of others, depending on the language. Each if statement will use the exact same keywords. Syntax highlighting can help show us what words really matter and which ones are just syntactical filling inherent with the language. In a novel, each verb conveys vastly different meaning and needs to be read in depth.

    Also, I had a bit of a problem with the following point on syntax highlighting:

    It encourages you to skim through code rather than understand it.

    If I’ve written some code, I need to be able to navigate the file quickly to find what I need to change. I already know the code, I can’t spend time reading through every line. Color easily sets out the structure of the code.

    1. 12

      I don’t use syntax highlighting because I want to see the syntax; I use it because I don’t. I program in white with a black background. Everything that’s “highlighted” is actually less visible than the normal text that represents the part of the program I care about.

      1. 8

        I agree with both @jw and @tedu, seeing how they say exactly what I wanted to say about it, but as one of the commenter pointed out in the article, Syntax Highlighting also does a very quick and rough linting/syntax check, if your “flota” won’t be colored, you will notice the misspelling instantly, if you forgot to close a quote, everything will be the same color.

        1. 4

          one other invaluable thing is rainbow-parenthesis.

          1. 1

            In homoiconic languages rainbow parens seem nice if you can’t rely on structural editing, but are actually hugely distracting because they draw attention to the individual parens when you should be focusing on the underlying structure and letting paredit handle matching. (It sounds a bit like the argument in the OP, except in this case it actually makes sense because structural editing is easy to automate, while understanding code isn’t.)

        2. 7

          For me syntax highlighting is a serious need. I’m dyslexic and have some issues with visual processing that causes things to get very jumbled. The highlighting helps me focus on pieces and follow the flow. I can do just fine with plain black and white as I have to on our HP/UX servers, I just go slower and tend to miss things. This also causes me problems reading text, like these comments, but I can usually compensate when the paragraphs do not get too long.

          1. 7

            I’ve lived in that world; I cut my teeth learning to program on an Apple ][+ compatible machine with a monichrome green monitor and latter on a PC with an amber monitor. Give up syntax highlighting and return to monochrome code? No thank you.

            For me, as a very visual person, syntax highlighting is mainly about visual pattern recognition. The spatial patterns formed by the colors and the highlighting act as landmarks to help me get my bearing at glance when I’m skipping around in familiar code, navigating by search.

            I think that a better anology than highlighting parts of speech in text would be to imagine reading a black-and-white map. After all, you can still tell rivers and water ways just by their labels, right? Or major streets from political boundaries? On the other hand, if you saw a map of a familiar region with meaningful colors but no labels there’s probably a good chance you’d instantly recognize what you’re seeing.

            For a similar navigation take, imagine if traffic signs all lacked color. For example, all stop signs in the U.S. have the word STOP in big letters in an octagonal frame. Do they really need to be red, too? Strictly speaking, no, but I certainly find navigating around a whole lot easier with color.

            1. 7

              Written languages contain significant amounts of redundancy, to the pniot wrhee you can raed tngihs wihch hvae been siflitangciny crurotepd.

              Try that with a compiler.

              1. 4

                I think this is a pretty absurd ‘case’.

                1. 3

                  Indeed, this is one of the few cases I’ve been annoyed by Lobsters' inability to downvote without classifying it as “spam”, “offtopic”, etc.

                2. 4

                  I did read the article, but it seems to be the case that everyone is commenting on the question it addresses rather than on its content, which is fortunate because that’s what I want to do, too. :) The below is probably pretty tedious to read, but we all seem to want to vent our feelings on this topic, and I have acquired quite a few! I’m sure people who dislike long comments have already skipped mine, so I won’t worry about it further.

                  I have long opposed syntax highlighting to the extent that it is typically used. However, I find some of the points others here have raised in its favor to be valid:

                  It is indeed the case that comments - when they don’t contain code! - can slow down code-comprehension by misleading the eye. Setting them in a harder-to-notice color alleviates this. I don’t personally like highlighted strings, but I can see a case that they’re similar.

                  With really long blocks of code having few visually-distinctive features, and working in a fixed-width font, it gets really difficult for the eye to find anything distinctive to mark its place by. This is why books are set in variable-width fonts with ragged-right justification and often nice, tall line-heights.

                  Since we tend to be obsessed with lining things up precisely, and we keep designing languages based on text files, which don’t provide any other way to line things up but spacing… Well, I definitely sympathize with wanting keywords or common punctuators to be noticeable, just to provide some variety. Of course, if every line ends in a semicolon, highlighting them doesn’t actually achieve that…

                  And then there are some points that I don’t regard as valid:

                  Sometimes, for programmers who have not worked in Lisp, balancing parentheses is a task that people find difficult. Rainbow parentheses have been mentioned. :) But electric parentheses, which turn to boldface momentarily only as they’re typed or as the insertion point is single-stepped past them, are less distracting, and faster to use for many purposes. I don’t know whether electric parens count as syntax highlighting or not, so take that how you will.

                  Skimming is a real need. It is made possible by providing distinctive features for the eye to focus on. A language in which there are none without special editor support is … well, making a choice to trade usability for … hopefully something! Can’t imagine what. Most features for which languages are touted have nothing to do with their syntax. Certainly many programmers are highly provincial regarding lexical issues that they consider to render code unreadable or beautiful, but is catering to bad attitudes a good feature?

                  Knowing whether keywords are spelled correctly is a completely spurious need. When you type a keyword five hundred times a day, you tend to spell it correctly every single time. The set of them in most languages is also small enough that you shouldn’t need the highlighting as a cue to know which ones exist, nor is it a good cue because it doesn’t help - as completion would - with identifiers you didn’t know about, only with confirming your guesses.

                  Knowing whether variable and function names are spelled correctly would be a wonderful thing, but in which editors is this possible? TextWrangler somehow gives me a squiggly underline for many of my misspellings, and also for many things which I spelled correctly… So I wouldn’t call that a win.

                  I haven’t seriously evaluated other editors in a few years, but I’m not aware of any that do anything clever for user-defined names. Library-defined names are explicitly listed for this purpose in some editors, but come on, when is that list ever going to be anywhere close to complete? The result of having it is that some small and arbitrary fraction of your symbols stand out vividly, while the rest do not; I regard this as worse than nothing.

                  But nobody, neither this author nor anyone in this thread so far, has mentioned my number one concern with syntax highlighting. The color schemes are terrible!!!

                  For example, I recently tried out Atom and Lighttable. I understand that these programs have profound differences, but my ability to use them was completely blocked by the same utterly superficial issues in each (some coloring-related, but mostly the difficulty of configuration), so I’m afraid I don’t remember in which one it was that I was able to figure out how to install themes.

                  It took far too long to find any which were dark-on-light as I prefer, because I get serious eye strain from light-on-dark. When I did, I discovered that the editor’s chrome wasn’t changed to match, so that tab titles and sidebars remained essentially illegible. But even worse, the actual color choices were horrifying in every theme I tried - very saturated colors; very hard on the eye. Nothing with the slightest subtlety to it. Highlighting on many, many more elements than I wanted. Fortunately, the colors were too numerous to easily remember, so if I were color-blind, I would not have found usability further impaired as I already couldn’t divine the logic behind the color assignments.

                  Okay… so I tried to edit a theme manually, and discovered that the taxonomy of lexical elements is the same for all programming languages. No recognition of the fact that, um, different languages are different. Well, that rather does give the theme designers an impossible task!

                  Those particular editors are markedly worse regarding color use than others I have tried, but even in the best editors, there are always a million different categories of lexical element, each highlighted in some arbitrary vibrant color to shout “forget what you were doing - look at me!”, and very seldom can unwanted categories be disabled. Good visual design is all about subtlety, and syntax-coloring editors lack it.

                  My perfect world? Languages, editors, and a file format designed around variable-width text. Is it really that weird? It would solve the entire readability problem. Yes, very unlikely ever to be accepted, I fully realize. Oh well!

                  1. 3

                    Edit your code without syntax highlighting, or at least settle for a minimalistic approach with just two colours (one for comments and one for code). Be warned that your code may actually look rather ugly without its colourful front, but at least you’ll be seeing it for what it really is.

                    The problem I have with this is that a lot of “what it really is” is composed of fixed pieces of the language that need to be manipulated in a particular way. Even in expressive or syntactically flexible languages (Haskell, Ruby, etc) there is a big difference between a keyword and a variable declaration. They’re different types of things than the words in a novel, because you can rephrase anything you like in a novel - you are more limited in your expressiveness when coding.

                    And the claim that it becomes “harder to detect bugs” strikes a bad chord with me. At the very least you could see a new class of bugs emerging (at least in interpreted languages) from the inadvertent use of reserved keywords and subtle misspellings of existing keywords.

                    The author’s point seems to be “we ought to read code more carefully,” which is quite reasonable but orthogonal to the issue of syntax highlighting in my mind.

                    1. 1

                      In vim (though I’ve since switched to emacs and haven’t bothered with a custom colour theme), I use a minimal set of syntax highlighting: comments are darkened (since I write mostly function comments) and strings are underlined (i.e. an unterminated string results in the rest of the program being highlighted). The rest is meant to approximate looking at an eInk display.

                      1. 1

                        With my editor’s color schemes, I found myself slowly reducing the amount of highlighting that gets done. At this point, I mainly highlight comments and strings.