Slightly meta: Turning off the syntax highlighting entirely seems a bit hardcore to me, however, <i>I always read each commit I do</i> via git diff / pull request view, which does not have syntax highlighting (other than red/green for removals/additions), and I always strive to make the diff look good for each commit (which means, doing one thing at a time in each commit, and making sure it reads well).<p>Unfortunately, not everyone I work with reads their code (yep, they write-commit-push-and-forget!) which sometimes makes code review a not so nice experience.<p>Please, please, <i>read your diffs</i> before sending code for review.
In the first few sentences he expressly states why you want highlighting:<p>> I couldn’t skip through the source that fast anymore and it became harder to read<p>Which, yes all the modifications to style (which is only his own code by the way) helped factor out. But I bet he'd be even better now with highlighting that he's made these additional changes to his style.<p>I worked for years without syntax highlighting. I am much more efficient with it for exactly the reason quoted. To each their own, but having visual cues to help is not a bad thing. I want my job to be easier.<p>I used to program black on white, then I was converted after jetbrains came out with an excellent dark theme with huge color variants that make code pop even better.<p>I'll never go back; I want my work and job easy, not made harder.
I predict that in a few months the author will turn a toned down version of syntax highlighting back on. All the advantages he stated were the result of disrupting his previous practices. Doing that forces you to reconsider how you do things and end up improving your skills. But they are learned lessons, not some mysterious side affect of less color.
No thanks.<p>The last time I could bare not using syntax highlighting I was still on MS-DOS.<p>Since Turbo Pascal 7 (released in 1992), syntax highlighting is a must have on my programming environment.<p>But I understand when we are talking about vim, people prefer an hardcore experience.
This seems to be an over-reaction to overly highlighted code. I work with Erlang in Emacs, and at first I couldn't believe how much of a Christmas tree my code looked like: every token had its own color, and it was really hard to read. Fortunately, erlang-mode has a setting to reduce the amount of highlighting. I don't think the proper reaction to a code base that has too many colors is to have none at all: trop c'est comme pas assez. I think many would be happy with some limited highlighting, for example comments, strings, and other constructions that can span multiple lines, incorrect escape codes, possibly-misspelled identifiers, etc. I don't really need or care that keywords and integer literals are colored differently.
I have 2.5 major distinctions made in my syntax highlighting, and it's common to almost all languages for me:<p>Comments are a shade that's near the background: I can read them if I focus on them, but otherwise they're not present when I'm reading code<p>Strings are a colourful colour, because the next visual distinction I want is between what's an operation or name, and what's data or literal. Numbers don't get this treatment because they're sufficiently obvious on their own.<p>The base text colour has a small distinction between keywords (darker) and everything else (lighter).<p>Sometimes I'll pull in another colour if I'm in something like Python for things like decorators, to create a distinction between code and meta-code.<p>This takes care of 95% of the visual distinguishing that's useful, and the rest is noise that adds cognitive load to track. As a bonus, because it's common to all languages in which I work, switching is easy because almost every language breaks down nicely between these categories.
Syntax highlighting only helps with the easy stuff. It doesn't do anything for<p><pre><code> std::array<std::shared_ptr<Window>, max_window_count>{};
</code></pre>
or<p><pre><code> s.lines()
.map(|bline| UnicodeSegmentation::graphemes(bline, true)
.collect::<Vec<&str>>())
.map(|line| wordwrapline(&line, maxline, maxword))
.collect::<Vec<String>>()
.join("\n")
</code></pre>
because nothing there is a language keyword.
I tried this multiple times over the last few years and it always didn't matter. It's not making a measurable difference but it looks less pleasant and I rather look at pretty things.
I found most of syntax highlighting easy distracting. But I couldn't turn it off completely as it felt <i>weird</i>. What I did is I modified theme who's colors I loved the most, so that it highlights less things, so that only some keywords would be highlighted like (break, return, for, if, etc). That way it helped me as screen didn't look to colorful, distracting and it didn't strain my eyes as before, but still providing some necessary information that pops out, to help me see the structure of my code better. But that is just me. I think I am not yet ready to give up syntax highlighting completely, but who knows, maybe one day. I am surely making progress towards that.
> Conditional syntax highlighting<p>I think that's the right approach. Different situations afford different tools. In normal usage, reading only in a single color is a real relief to me; but of course it's typically easier to find missing delimiters and such with syntax highlighting.<p>I've had this shortcut in my vim configuration for a very long time and I use it frequently:<p><pre><code> nmap <F11> :if exists("syntax_on") \| syntax off \| else \| syntax enable \| endif \|<newline><C-g>
</code></pre>
Similarly, there should be actual different flavours of highlighting for different tasks. I have configured a very light highlighting which highlights mostly control flow words (if, while, for, return etc) and maybe strings. It's much better than the colorful default or syntax off for many situations. On other occasions it might be useful to highlight all variable declarations, etc.<p>I have come to think that it's the same with programming languages: Different languages require you to type different things explicitly. Sometimes that's beneficial but often it hurts. For example, typing a function signature is much more convenient in python (just variable names), but when debugging the explicitness of a more rigid type system often helps finding bugs. Similarly typing "const" or the precise type of integer is really annoying in many situations. It's visually distracting and shifts the focus on alignment or ordering of statements, instead of the problem to be solved. On the other hand, sometimes these things are just important. It would be very nice to have a programming environment where these details can be hidden most of the time and only turned on when really needed.
I like to highlight just the places where you are defining new variables/functions/types so that the definition is easy to spot. What is the point of highlighting keywords? I suspect that highlighting engines do it simply because it's easy to do, not because it's useful.<p>It looks like this:
<a href="http://david.rothlis.net/code_presentation/distracting_syntax_highlighting/" rel="nofollow">http://david.rothlis.net/code_presentation/distracting_synta...</a>
On an average day, I use visual studio for 4 languages. There's C#, HTML, JS, and some old VB.net depending on how old the code I'm working with is. Many times the same fix/feature will touch all of them. That's just on the .net stuff. Having the same general colorization scheme in place is probably all that makes skimming through code possible for me.<p>I remember feeling like the game changed when I went from grey and yellow on black to grey and holy crap other colors for other things on blue from turbo pascal 3 to 7. You can't take it back from me now. I've had my syntax highlighted for 2/3's of my life now, I'm not giving it back.
This seems like old-is-new waxing, reaching for some reason the old way is better.<p>> Initially, turning off syntax highlighting felt weird. I couldn’t skip through the source that fast anymore and it became harder to read.<p>It does, that's the point of syntax highlighting. This isn't a good thing(tm).<p>> Even though this appeared to be an impairment I found it to be the strongest argument for making the switch. By forcing me to read the code more carefully, it made me understand it better<p>I tried not highlighting a bunch of times, it's called switching from my IDE to vi for whatever reason. It's not better for me.
I think syntax highlighting probably evolved before editors and IDEs could flag coding mistakes. A lot of the rationale for it no longer applies, e.g. coloring strings a certain way so if you forgot the terminating quotation mark, the rest of the file would change to that color and you'd know you screwed up.<p>I haven't used syntax highlighting for years. My IDE highlights mistakes and compiler errors, and everything else is black. It's actually a lot easier on my eyes, and the errors stand out a lot more because they are the only colored parts of the text. I only use highlighting these days to separate tags from content in markup languages like XML and HTML, where I still find it helpful.<p>This is all personal preference anyway, and it doesn't matter very much. But I do encourage people to try going without syntax highlighting for a few days. You may find that you didn't really need it, or that it was compensating for sloppy coding, and you may not want to switch it back on at the end of the experiment.
I worked for years with SimpleText/TextEdit on the Mac (Classic/OS X) and Pico on the server.<p>I felt syntax highlighting was a gimmick that distracted me from my Monaco 10 with no anti-alias perfection.
If I needed to do some repetitive editing beyond a simple find/replace, I'd write a small shell script. I was kind of proud of my minimalism. You can do a lot with native Carbon/Cocoa key bindings alone. Life was good.<p>Then someday I saw a video of someone doing crazy work in Vim. Flying. I <i>had</i> to learn that.
I forced my self to use Vim exclusively for one job, from beginning to end.
I kept watching similar videos to get over the nightmarish frustration that is anyone's first week or so in Vim.
But after that, I was completly hooked.<p>However, I still have warm feelings when I open some code in TextEdit. Black, 10px Monaco text over a 90 by 30 white background. Ah.
This experiment applies to textbooks as well.<p>I looked over an old edition of Halliday+Resnick once, a well thought of lower division physics book. The text was substantially the same but it was black and white. This meant no <i>syntax highlighting</i> and also no glossy paper. The result was a LOT easier to read.<p>Glossy paper is a designery thing to do for deeper blacks but it's less readable. Indeed that's why actual designers like matte finish MBPs, because you don't want to read with a 20% opacity of yourself staring at you.
Ok, this thing with young developers going into grandfather-mode is starting to get old.<p>Acknowledge that it's a hipster thing to use vi and fixed gear bikes, and carry on with your life.
Coming from an age before syntax highlighting was a thing, I would hate for us to go back to it. I first saw it in Turbo C and it was amazing. This is another tool that we can use to give us better code quality.<p>However, some folks is pushing the syntax highlighting into realms of an art piece. I had a coworker that would using bold, italics, different font sizes, as well as colours.
I totally agree with this, and use `:syntax off`, but comments really mess with visual clarity. For dimmed comments, I sometimes switch to nofrils.<p><a href="https://www.robertmelton.com/2016/04/10/syntax-highlighting-off/" rel="nofollow">https://www.robertmelton.com/2016/04/10/syntax-highlighting-...</a>
I don't turn syntax off, but I hate rainbow in my IDE. I usually use bold for keywords, different colors for comments and string literals, underscore for class members (for Java). Basically that's all. I don't need any other highlighting, it's just a noise for me which makes it harder to read the code.
It probably goes well with typing on one of these horrible new Macbook keyboards - it makes you think twice before pressing each key, thus making your code even more thought-out and succinct.<p>As one of those programmers who were long ago forced to use no syntax highlighting (because monitors were monochrome), I say no thanks.
I think he may have a point, but I think there's a minimal highlighting configuration that is helpful, yet not obnoxious: one where comments and constants are highlighted in their colors.<p>Comments are pretty much universally "skimmable" if what you want to get at is the code, and also completely unrelated to actual code (other than describing it), so I think they deserve their own color and that it is helpful. Also, conversely comments in their own color stand out from the code so that if you're looking for descriptions, they are easier to find.<p>Colors also being useful for constant values (strings and numeric ones alike) because at least I really want something hard coded to stand out. Sometimes it should be hard coded, sometimes it shouldn't, but pretty much always, what the hard coded content _is_, is of interest.
I do use syntax highlighting, but only with two additional subtle colors (one for literals, another for language keywords). Many editors come with themes resembling a decorated Christmas tree.
I'd argue that you could learn to read code carefully, understand what it's doing, and write good code without losing the convenience of syntax highlighting.<p>Unless the color scheme you were using really was so garish that it hindered your ability to improve your skills as a software engineer, in which case you could probably find a more subtle color scheme that would give you the same benefits as turning it off did. I've heard great things about the solarized color schemes. I use wombat myself.
Not sure about all the benefits and whatnot but I've learned to like 'syntax almost off' better. I do want to differentiate between comments though. And vim adds some of it's own colors to stuff like the linenumbers that I dislike.<p>So I use this. <a href="https://github.com/Kareeeeem/vim-walou" rel="nofollow">https://github.com/Kareeeeem/vim-walou</a><p>There's more stuff like it but I wanted to pick my own gray values and dislike pure white on pure black.
The Acme/Plan9 folk were bullish on coding without syntax highlighting (and with proportional fonts). I spent a while trying to use Acme a couple of years back and agree that it's not essential, but I switch programming languages so often these days (Python/Go/Clojure plus the occasional Java/C#) that I need it to remind myself of what goes where in each language.<p>But I can see the benefit of forcing you to make your code more readable in general.
My solution for half a year now, after years of a bajillion themes, it's hard to go back, using a light theme with dark text works to an extent but I code mostly at night so I need a dark theme in general. Just use about 2 shades of grey and one other soft color. <a href="https://i.imgur.com/FHALH2G.png" rel="nofollow">https://i.imgur.com/FHALH2G.png</a> -- or search for Phoenix theme
In my team, an old geek man also have told me about `syntax off`. I also have tried a couple of times. But it makes my eyes hurt cause of looking carefully at every word, tokens. Another thing I consider to build my workspace is 'attractive'. Code with proper color highlight make it sexy to work with.
syntax off, proportional width, (<a href="https://twitter.com/rob_pike/status/567476552187641856" rel="nofollow">https://twitter.com/rob_pike/status/567476552187641856</a>), all code right aligned, ZWS for tabs
I have the feeling most of this isn't a direct problem of syntax highlighting.<p>Most people simply highlight dumb stuff in their code.<p>For example, comments often have a bad contrast and stuff like brackets, curly braces or parathesis have high contrast.
I think a large part of the issue with syntax highlighting is that our "standard" for syntax highlighting is rather dumb. A few thoughts:<p>- Who the hell would write prose by making all the verbs blue, the nouns red, and the adverbs green (or something to that effect). That's what we do for code. Something togglable a-la iA Writer might make sense, though. At the same time, I can sort of understand, though, because we're almost always in "edit" mode for code, very rarely in pure "write".<p>- I find having lint-errors highlighted provides a similar nudge to the "squiggly-red underline spellcheck".<p>- Our editors aren't configurable enough with regards to typography. I like to use subtle weight changes, highlighting "headings" and whatnot, and very few tools seem to make that change available.<p>- Semantic highlighting seems super interesting, but I haven't found a tool that I like yet.<p>One project I'd love to see is to get a bunch of folks together to do some proper layout-by-hand on code -- Given 100% control over typography, how would you format it to maximize readability, minimize distraction, highlight relevant contextual knowledge, etc? And then work to push tools in a direction that they support configuration to allow for said tasks.
I like to take advantage of my tooling to make my life easier. Writing good code is difficult enough without imposing additional constraints upon yourself to make it more challenging.