11 ms·

Turning off syntax highlighting

172 points by dudzik 10y ago

return0 10y ago
I thought broscience was supposed to stay in the gyms.
jakub_g 10y ago
Slightly meta: Turning off the syntax highlighting entirely seems a bit hardcore to me, however, I always read each commit I do 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). 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. Please, please, read your diffs before sending code for review.
- taeric 10y ago
  I'm just trying to convince folks to actually write commit messages. :) I don't think anyone is relying on diffs to find bugs. Do they? Similarly, before doing something complicated at work, please talk about it with a coworker first. Last thing I want is to try to decipher a complicated piece of code without a good motivator as to why I'm doing so. Advanced warning is a great motivator.
  - jmhain 10y ago
    I do this, but not mainly to find bugs, though on rare occasions I do. I almost always find something, e.g. stylistic aberrations, overzealous changes from an intellij refactor, debug statements I forgot to remove, part of another change I'd thought I'd stashed but somehow ended up in the commit. It blows my mind that anybody would not read their diffs.
    - taeric 10y ago
      Fair. I try to do this. I still make mistakes, I'm sure. This ultimately comes down to a "good intentions." Would be neat to make a mechanism out of it.
- DSMan195276 10y ago
  I agree completely. On that note, I also consider `git add -A` to be horrible practice. Adding files manually makes you tons more aware of what changes you actually made, and also prevents you from accidentally adding extra files you don't want. I also recommend people to look at the Linux kernel git history for good examples of how to use git well. Even if you have no knowledge of kernel code (and most people don't) it's still extremely clear how each commit makes a single change and is fairly easy to review. Now, the Linux kernel has the luxury of being able to demand people fix their commits, but that's not to say you shouldn't strive to reach similar states in your commits.
  - OJFord 10y ago
    > I also consider `git add -A` to be horrible > practice. Adding files manually makes you tons more > aware Agreed, but I take it further than that - I always use `git add -p` because it forces me to read through everything, and make everything in the commit deliberate. Even if you think you just made a slight change to a file or two and definitely want everything, you'd be surprised how often it lets me pick up some aesthetic change, comment change, or dependency version bump that's completely unrelated to the commit message I'm about to write.
    - jakub_g 10y ago
      I am in the other extreme: I always use `git add -A` (but I read the diff before) and avoid doing more than one thing in the first place (which would make me want to use `git add -p`). IMO it is an antipattern to do bazillion changes at once, and then do several commits out of it (unless you really know what you're doing) - because you commit a state of the repo that (probably) never existed. I prefer to do change, commit, do change, commit, and at the end do interactive rebase and perhaps squash some things together.
      - msarchet 10y ago
        > because you commit a state of the repo that (probably) never existed The state doesn't exist in the repository until the code has been committed - so your statement is a little backwards. Sure the code might never have only had that edit in it, but the repository has no changes until a commit is made.
- artursapek 10y ago
  Agreed. The first thing the older guys taught me at my first internship was `git add --patch`.
- robohamburger 10y ago
  Learning to this both after writing the code and being able to plan what chunks of works I do when is a game changer and really useful when you work on a team. I sometimes find waiting until I am done working on something to break it up into small commits can be a headache.
- hawski 10y ago
  I prefer doing this with 'git gui'. It's standard and is very simple to use. What is important you can easily select chunks or lines to stage or unstage.
- jasoncchild 10y ago
  >Slightly meta: Turning off the syntax highlighting entirely seems a bit hardcore to me, however, I always read each commit I do 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) ...alas, some projects require 1 commit per pr, max... ...then again, if you do a 1:1 commit:change as default the rebase msg is much easier to structure :)
- hellofunk 10y ago
  I'm amazed someone wouldn't read their diffs, just for their own sanity. It's a great summary to remind yourself what you just did to resolve an issue. And what if your cat just walked over your keyboard while you weren't looking? Your diff will tell you this. Silly but meaningful example.
- Kubuxu 10y ago
  I always use `git commit -v` (with alias). You get the diff in the editor when you write commit message.
aratno 10y ago
I totally agree with this, and use `:syntax off`, but comments really mess with visual clarity. For dimmed comments, I sometimes switch to nofrils. https://www.robertmelton.com/2016/04/10/syntax-highlighting-off/ https://www.robertmelton.com/2016/04/10/syntax-highlighting-...
- dudzik 10y ago
  OP here Great addition. For me this is a use case for conditional highlighting. What I do in my code additionally is to avoid block comments. So you can differentiate them better from your code.
- mseepgood 10y ago
  Comments are the most important part of code. They should not be dimmed. If anything, they should be the only thing that is highlighted.
  - dudzik 10y ago
    I think that this is dependent on what you are trying to do. If you want to understand what a program does than this is the way to go. If you want to program than you don't necessarily need the comments to be that visible.
  - aratno 10y ago
    I'm arguing that dimming them makes them easier to see. Code and comments are interspersed, and are each harder to see when they're the same color.
    - majewsky 10y ago
      I use a slightly more intense background color on comments to make them stand out while still being readable enough.
  - enneff 10y ago
    My highlighting scheme is to very slightly dim comments, because they tend to be more dense than code. For example: http://imgur.com/a/bxfBO http://imgur.com/a/bxfBO
Philipp__ 10y ago
I found most of syntax highlighting easy distracting. But I couldn't turn it off completely as it felt weird. 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.
BaNzounet 10y ago
Author should provide some before/after code to show how it affected his coding style.
deleted 10y ago
[deleted]
pjmlp 10y ago
No thanks. The last time I could bare not using syntax highlighting I was still on MS-DOS. Since Turbo Pascal 7 (released in 1992), syntax highlighting is a must have on my programming environment. But I understand when we are talking about vim, people prefer an hardcore experience.
- yongjik 10y ago
  Huh, I thought being "hardcore" about vim meant writing your own syntax highlighting rules. (Which isn't that hard, though vimscript does have some weird quirks.)
  - kazinator 10y ago
    Vim's syntax coloring is more powerful than what I have been able to find in other systems. It can handle nested constructs quite well. If you have a situation in which two languages can be embedded in each other. I am using Vim dynamically, calling it out of CGIT. For example: http://www.kylheku.com/cgit/txr/tree/genman.txr http://www.kylheku.com/cgit/txr/tree/genman.txr When you access this file, CGIT runs a syntax highlighting shell script where you can hook in multiple approaches (e.g. based on file suffix). I hacked this script to run Vim via Expect, to load the text and save the HTML with :TOHtml. As you can see, the TXR pattern language and TXR Lisp are nicely separated in the output. The identifiers are colored differently---even in cases when they are the same! Look for a purple (do ...), which is a directive in the TXR pattern language to enclose and evaluate a bunch of Lisp, and green (do ...), which is a totally unrelated construct in TXR Lisp: one of the forms that support explicit partial evaluation. When I'm coding in TXR, Vim is quite accurate in identifying mistakes like string literals not being closed and parentheses not being balanced and such, or various tokens being malformed and whatnot. It can figure it out in spite of levels of nesting. It significantly reduces such errors.
- vvpan 10y ago
  I don't think that's what "hardcore" means to a vim user. Vim is all about convenience for me.
- geocar 10y ago
ncauneia 10y ago
Is disabling syntax highlighting the new standing desk?
jablan 10y ago
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. As one of those programmers who were long ago forced to use no syntax highlighting (because monitors were monochrome), I say no thanks.
stevebmark 10y ago
Not this again "We should remove all color from traffic lights and make people remember which position is what"
- taeric 10y ago
  Somewhat of a false dichotomy, no? I'm not hurrying up to remove syntax highlighting of source, but I also don't particular care that I don't have it in email snippets. Or in many books. (Of course, now I need to go verify that my books don't actually have some form of typographic trick for source code. Other than tt.) I have gone for a more reserved theme in my editor lately. Currently on solarized again, but probably going back to zenburn soon.
- michaelmrose 10y ago
  Surely this would make people slow down and pay attention or you know just crash more.
  - rosser 10y ago
    There was an article shared here on HN some time back about the guy who got one Dutch town to remove the warning signs on its traffic circles. Accident rates dropped sharply.
  - s_kilk 10y ago
    Right, but realistically they'd just crash more and then what's been achieved? Some of us get to feel smug about how the daft plebs aren't hard-core enough to navigate without colored traffic lights?
    - asp_hornet 10y ago
      not OP but I believe that was the point he was making
- flukus 10y ago
  That would be fun. There are a significant amount of people in my building that don't realize the top light means the elevator is going up and the bottom light means it's going down.
z3t4 10y ago
I only color comments and strings.
- satysin 10y ago
  Same. Works well for me e.g. http://i.imgur.com/RMrslmu.png http://i.imgur.com/RMrslmu.png
  - qznc 10y ago
    Comments and literals (numbers, strings, NULL, etc) here. http://imgur.com/a/kRbhG http://imgur.com/a/kRbhG I tried no-syntax-highlighting for a while, but found that a little bit is nice.
drothlis 10y ago
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. It looks like this: http://david.rothlis.net/code_presentation/distracting_syntax_highlighting/ http://david.rothlis.net/code_presentation/distracting_synta...
- Adverblessly 10y ago
  To me, all three look bad. Eclipse - no colors for different things, hard to find what I'm looking for (if I compare to the Emacs example, if I was looking at this code trying to figure out what members this class has I'd be looking for brown and finding it much more quickly) Emacs - terrible color scheme, both the brown and the green are too bright, not enough contrast to read. Proposed - all the bold text hurts my eyes and distracts me from everything else. In my crazy theme almost every "thing" has its own color, and it is very easy to find what I want by looking for the right "thing" or combination of things. As an example for where highlighting keywords would help (which is what you mentioned in your post), if I'm looking for "that for loop that does the main logic" I'd look for the place with the small blue blob on the left and a long bright blob to the right (if it was an "if" likely both blobs would be smaller ;)).
- maaaats 10y ago
  That code is pretty unreadable to begin with, don't think any highlighting or not can save it. But I prefer the Eclipse one, it lets you quickly find the various blocks (public, protected etc.) when skimming through. The proposed scheme is one giant blob.
- eikenberry 10y ago
  One of the points of syntax highlighting is to create visual patterns you can recognize. Highlighting keywords may help with this. Have you tried disabling keywords highlighting and seeing what difference it makes in reading your code?
the_mitsuhiko 10y ago
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.
- foobarian 10y ago
  I also don't find the syntax coloring to make a big difference for me. What does though is the semantic feedback/navigation in the IDE. When I joined a Java shop for the first time I was all gung-ho about sticking to my 80x24 terminal and emacs and to heck with the point-and-click crowd who couldn't do their work without a graphical UI. Then my new manager got me to try Eclipse for a week. I humored him and discovered that I was an order of magnitude more productive with Eclipse's semantic features like on-the-fly compile error underlining, code autocomplete, and navigation. It really was a humbling experience.
z0r 10y ago
syntax off, proportional width, (https://twitter.com/rob_pike/status/567476552187641856 https://twitter.com/rob_pike/status/567476552187641856), all code right aligned, ZWS for tabs
- qznc 10y ago
  Proportional fonts + elastic tab stops [0]. I would love to have this working. Unfortunately, if you really depend on elastic tab stops you break the formatting for everybody who does not use it. [0] http://nickgravgaard.com/elastic-tabstops/ http://nickgravgaard.com/elastic-tabstops/
- TurboHaskal 10y ago
  - Hey guys we wrote gofmt so all code looks the same. - Great! Now we can finally get things done and stop bikeshedding! - Now about that syntax highlighting of yours...
mseepgood 10y ago
Turning syntax coloring off was the best decision in my career. I have never looked back.
- dimman 10y ago
  I wouldn't go as far as to say it was my best decision in my career, however it was an important one. I've noticed how I've gone from "click-friendly" GUI's and window managers like Gnome/KDE to Fluxbox, turned syntax highlighting off and at the same time increased my productivity/effectiveness. At first I missed the "fanciness", the new felt boring and pale, however as time passed it made me realize that I'm now focusing on the important things and I'm in control. So yes okay, it's one of my best decisions.
- calebm 10y ago
  Writing programs all on a single line was the best decision of my career! The enlightenment writing everything on a single line imparted to me was nothing short of an epiphany...
- enneff 10y ago
  It has definitely been a big improvement to my working life.
- pc86 10y ago
  You cannot be serious.
douche 10y ago
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.
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
djhworld 10y ago
I don't agree with the idea whatsoever, but I really like the minimalist design of the authors website.
jowiar 10y ago
I think a large part of the issue with syntax highlighting is that our "standard" for syntax highlighting is rather dumb. A few thoughts: - 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". - I find having lint-errors highlighted provides a similar nudge to the "squiggly-red underline spellcheck". - 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. - Semantic highlighting seems super interesting, but I haven't found a tool that I like yet. 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.
- abecedarius 10y ago
  > Given 100% control over typography, how would you format [code] to maximize readability There was a book on this, whose title I'm blanking on. Anyone remember? Color wasn't an element, since it was an older book focusing on printing on paper.
  - marxidad 10y ago
    Bjarne Stroustrup's C++ book used a proportional font with tabular spacing.
    - abecedarius 10y ago
      So did the book I was thinking of, but it tried more fancier stuff too and iirc reported on some experiments in code reading.
  - pYQAJ6Zm 10y ago
    Kinda rings a bell for me, although not from a book, but some LaTeX manual. Maybe this helps: http://tug.ctan.org/macros/latex/contrib/algorithm2e/doc/algorithm2e.pdf http://tug.ctan.org/macros/latex/contrib/algorithm2e/doc/alg...
zvrba 10y ago
Yes, let's use roman numerals too lest we calculate too efficiently and be able to express more complex calculations more easily.
- Mr_T_ 10y ago
  You mixed it up. Syntax highlighting is like doing arithmetic using colored rods: https://groups.google.com/forum/#!msg/golang-nuts/hJHCAaiL0so/kG3BHV6QFfIJ https://groups.google.com/forum/#!msg/golang-nuts/hJHCAaiL0s... Roman numerals is object-oriented design: https://groups.google.com/d/msg/comp.os.plan9/VUUznNK2t4Q/Ff_uWhnsbwAJ https://groups.google.com/d/msg/comp.os.plan9/VUUznNK2t4Q/Ff...
vbezhenar 10y ago
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.
- qznc 10y ago
  What I don't understand is that people want to highlight keywords. Bold is a very strong highlight compared to coloring it. However, keywords (if, while, return) can probably be guessed from the indentation alone. There is little need to guide my focus to them even more.
  - protomikron 10y ago
    Interesting, for me it is the other way around. I use syntax highlighting (but mostly go with Vim's shipped defaults) and like the keyword highlighting the most. E.g. looking at Python code, it highlights 'def', 'if', 'else', 'elif', 'for', 'while', etc. in orange, function identifiers in cyanish and literals (integer, float, strings) redish (on terminal with blackish background). If I look at code, it helps me to find the beginning of a function and the parts where logic branches (conditions, loops, etc.) start. Some time ago I wrote code without highlighting and although it is obviously possible I found it harder (i.e. it took me more time) to navigate for my eyes. Maybe just using bold or italic would be enough, though. However thinking about it, it might be a nice experiment to highlight identifiers with a unique color (or at least highlight all occurrences of an identifier below the cursor - I think Eclipse does something like that).
  - vbezhenar 10y ago
    It allows to quickly understand general structure of the code. Indentation helps too, but it's not enough to quickly distinguish between "for" and "if", for example. Or may be I just got used to it.
eikenberry 10y ago
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.
- geocar 10y ago
  That's what robertmeta did[1], but when I turned off syntax highlighting I left it off. [1]: https://www.robertmelton.com/2016/04/10/syntax-highlighting-off/ https://www.robertmelton.com/2016/04/10/syntax-highlighting-...
- fmueller 10y ago
  I turned off syntax highlighting several months ago and never wanted to turn it back on. Scanning the code is now as good as it was before. And understanding und structuring the code got better because I'm no longer distracted by unimportant parts of the code.
jstimpfle 10y ago
> Conditional syntax highlighting 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. I've had this shortcut in my vim configuration for a very long time and I use it frequently: nmap <F11> :if exists("syntax_on") \| syntax off \| else \| syntax enable \| endif \|<newline><C-g> 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. 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.
apetrovic 10y ago
Even better - we should ditch color monitors altogether. You know, to be edgy and different.
- rsl7 10y ago
  Sure, also let's chuck scrollback in our terminals. What's done is in the past, people.
  - vacri 10y ago
    A shiver actually ran up my spine...
- zbraniecki 10y ago
  My first thought was that if we close our eyes while programming, that will force us to really understand the code we write... As someone put it, it feels like "broscience".
- koenigdavidmj 10y ago
  I would totally code on an e-ink screen if it was larger than a Kindle.
tambourine_man 10y ago
I worked for years with SimpleText/TextEdit on the Mac (Classic/OS X) and Pico on the server. 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. Then someday I saw a video of someone doing crazy work in Vim. Flying. I had 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. 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.
codepunker 10y ago
Let's not use headlights anymore too... This will force the us to drive more carefully and reduce speed to avoid a potential disaster.
- dudzik 10y ago
  "The removal of road markings is to be celebrated. We are safer without them" - https://www.theguardian.com/commentisfree/2016/feb/04/removal-road-markings-safer-fewer-accidents-drivers https://www.theguardian.com/commentisfree/2016/feb/04/remova...
k__ 10y ago
I have the feeling most of this isn't a direct problem of syntax highlighting. Most people simply highlight dumb stuff in their code. For example, comments often have a bad contrast and stuff like brackets, curly braces or parathesis have high contrast.
kpil 10y ago
Ok, this thing with young developers going into grandfather-mode is starting to get old. Acknowledge that it's a hipster thing to use vi and fixed gear bikes, and carry on with your life.
bluejekyll 10y ago
In the first few sentences he expressly states why you want highlighting: > I couldn’t skip through the source that fast anymore and it became harder to read 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. 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. 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. I'll never go back; I want my work and job easy, not made harder.
- dudzik 10y ago
  > which is only his own code by the way Yes, working in a team is definitely a different endeavor. If your teammates or organization aren't open to changes to the style guide then I wouldn't recommend turning syntax highlighting off.
- taneq 10y ago
  This was my thought - he's altered his style to be more readable without syntax highlighting, which is all well and good for him, but doesn't necessarily translate to it being more readable with syntax highlighting, and so is not necessarily a grand thing for his teammates who still use it.
rcarmo 10y ago
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. But I can see the benefit of forcing you to make your code more readable in general.
CalChris 10y ago
This experiment applies to textbooks as well. 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 syntax highlighting and also no glossy paper. The result was a LOT easier to read. 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.
Animats 10y ago
Syntax highlighting only helps with the easy stuff. It doesn't do anything for std::array<std::shared_ptr<Window>, max_window_count>{}; or s.lines() .map(|bline| UnicodeSegmentation::graphemes(bline, true) .collect::<Vec<&str>>()) .map(|line| wordwrapline(&line, maxline, maxword)) .collect::<Vec<String>>() .join("\n") because nothing there is a language keyword.
- wmu 10y ago
  A highlighter in Visual Studio is able to distinguish (at least) preprocesor definitions, variables and class names.
- jobigoud 10y ago
  > because nothing there is a language keyword What editor are you using where the highlighter doesn't identify user-defined types, member functions, namespaces, local variables? Maybe you don't realize it has these capabilities because it's configured to highlight them with the default?
gnuvince 10y ago
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.
iKlsR 10y ago
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. https://i.imgur.com/FHALH2G.png https://i.imgur.com/FHALH2G.png -- or search for Phoenix theme
fatbird 10y ago
I have 2.5 major distinctions made in my syntax highlighting, and it's common to almost all languages for me: 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 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. The base text colour has a small distinction between keywords (darker) and everything else (lighter). 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. 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.
- chrismorgan 10y ago
  If making comments invisible is at all helpful, they’re being seriously misused. Comments are supposed to explain what’s going on, and thus make things easier. Hiding them should be very counter-productive.
  - pYQAJ6Zm 10y ago
    I do the same thing. It’s not as much hiding the comments as making them less attention-grabbing when they are not needed.
  - fatbird 10y ago
    As pYQAJ6Zm says: they're not invisible, but when I'm looking at code, they're easily ignored, and when I'm looking at comments, they're easily located. Using solarized dark, the background is Base 03 'bright black' (#002833) and the comments are Base02 'black' made a bit lighter (#004f62). Comments are for holding details: I shouldn't need them to understand code, at least superficially/structurally. But they should be there if I need to drill down on something a bit, and making it so that focusing on that extra detail is easily skipped or applied makes the overall code reading much more fluid.
jug 10y ago
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. 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. 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.
EmmEff 10y ago
FFS, this article is nonsense. If you're not disciplined enough to properly read and review code whether it's colourful or not, syntax highlighting is the least of your worries. Stop deflecting blame for being a poor coder
deleted 10y ago
[deleted]
jack9 10y ago
This seems like old-is-new waxing, reaching for some reason the old way is better. > Initially, turning off syntax highlighting felt weird. I couldn’t skip through the source that fast anymore and it became harder to read. It does, that's the point of syntax highlighting. This isn't a good thing(tm). > 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 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.
- jablan 10y ago
  You know that vim can syntax-highlight too, right?
twblalock 10y ago
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. 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. 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.
dinhnv 10y ago
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.
Yaggo 10y ago
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.
bbarn 10y ago
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. 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.
Kareeeeem 10y ago
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. So I use this. https://github.com/Kareeeeem/vim-walou https://github.com/Kareeeeem/vim-walou There's more stuff like it but I wanted to pick my own gray values and dislike pure white on pure black.
barat 10y ago
Is there any example for this so-called conditional highlighting that we could take a look at ?
yitchelle 10y ago
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. 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.
draw_down 10y ago
No, no, no.
Rudism 10y ago
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. 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.

172 points by dudzik 10y ago

I thought broscience was supposed to stay in the gyms.

Slightly meta: Turning off the syntax highlighting entirely seems a bit hardcore to me, however, I always read each commit I do 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). 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. Please, please, read your diffs before sending code for review.

taeric 10y ago
I'm just trying to convince folks to actually write commit messages. :) I don't think anyone is relying on diffs to find bugs. Do they? Similarly, before doing something complicated at work, please talk about it with a coworker first. Last thing I want is to try to decipher a complicated piece of code without a good motivator as to why I'm doing so. Advanced warning is a great motivator.
- jmhain 10y ago
  I do this, but not mainly to find bugs, though on rare occasions I do. I almost always find something, e.g. stylistic aberrations, overzealous changes from an intellij refactor, debug statements I forgot to remove, part of another change I'd thought I'd stashed but somehow ended up in the commit. It blows my mind that anybody would not read their diffs.
  - taeric 10y ago
    Fair. I try to do this. I still make mistakes, I'm sure. This ultimately comes down to a "good intentions." Would be neat to make a mechanism out of it.
DSMan195276 10y ago
I agree completely. On that note, I also consider `git add -A` to be horrible practice. Adding files manually makes you tons more aware of what changes you actually made, and also prevents you from accidentally adding extra files you don't want. I also recommend people to look at the Linux kernel git history for good examples of how to use git well. Even if you have no knowledge of kernel code (and most people don't) it's still extremely clear how each commit makes a single change and is fairly easy to review. Now, the Linux kernel has the luxury of being able to demand people fix their commits, but that's not to say you shouldn't strive to reach similar states in your commits.
- OJFord 10y ago
  > I also consider `git add -A` to be horrible > practice. Adding files manually makes you tons more > aware Agreed, but I take it further than that - I always use `git add -p` because it forces me to read through everything, and make everything in the commit deliberate. Even if you think you just made a slight change to a file or two and definitely want everything, you'd be surprised how often it lets me pick up some aesthetic change, comment change, or dependency version bump that's completely unrelated to the commit message I'm about to write.
  - jakub_g 10y ago
    I am in the other extreme: I always use `git add -A` (but I read the diff before) and avoid doing more than one thing in the first place (which would make me want to use `git add -p`). IMO it is an antipattern to do bazillion changes at once, and then do several commits out of it (unless you really know what you're doing) - because you commit a state of the repo that (probably) never existed. I prefer to do change, commit, do change, commit, and at the end do interactive rebase and perhaps squash some things together.
    - msarchet 10y ago
      > because you commit a state of the repo that (probably) never existed The state doesn't exist in the repository until the code has been committed - so your statement is a little backwards. Sure the code might never have only had that edit in it, but the repository has no changes until a commit is made.
artursapek 10y ago
Agreed. The first thing the older guys taught me at my first internship was `git add --patch`.
robohamburger 10y ago
Learning to this both after writing the code and being able to plan what chunks of works I do when is a game changer and really useful when you work on a team. I sometimes find waiting until I am done working on something to break it up into small commits can be a headache.
hawski 10y ago
I prefer doing this with 'git gui'. It's standard and is very simple to use. What is important you can easily select chunks or lines to stage or unstage.
jasoncchild 10y ago
>Slightly meta: Turning off the syntax highlighting entirely seems a bit hardcore to me, however, I always read each commit I do 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) ...alas, some projects require 1 commit per pr, max... ...then again, if you do a 1:1 commit:change as default the rebase msg is much easier to structure :)
hellofunk 10y ago
I'm amazed someone wouldn't read their diffs, just for their own sanity. It's a great summary to remind yourself what you just did to resolve an issue. And what if your cat just walked over your keyboard while you weren't looking? Your diff will tell you this. Silly but meaningful example.
Kubuxu 10y ago
I always use `git commit -v` (with alias). You get the diff in the editor when you write commit message.

aratno 10y ago

I totally agree with this, and use `:syntax off`, but comments really mess with visual clarity. For dimmed comments, I sometimes switch to nofrils. https://www.robertmelton.com/2016/04/10/syntax-highlighting-off/ https://www.robertmelton.com/2016/04/10/syntax-highlighting-...

dudzik 10y ago
OP here Great addition. For me this is a use case for conditional highlighting. What I do in my code additionally is to avoid block comments. So you can differentiate them better from your code.
mseepgood 10y ago
Comments are the most important part of code. They should not be dimmed. If anything, they should be the only thing that is highlighted.
- dudzik 10y ago
  I think that this is dependent on what you are trying to do. If you want to understand what a program does than this is the way to go. If you want to program than you don't necessarily need the comments to be that visible.
- aratno 10y ago
  I'm arguing that dimming them makes them easier to see. Code and comments are interspersed, and are each harder to see when they're the same color.
  - majewsky 10y ago
    I use a slightly more intense background color on comments to make them stand out while still being readable enough.
- enneff 10y ago
  My highlighting scheme is to very slightly dim comments, because they tend to be more dense than code. For example: http://imgur.com/a/bxfBO http://imgur.com/a/bxfBO

Philipp__ 10y ago

I found most of syntax highlighting easy distracting. But I couldn't turn it off completely as it felt weird. 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.

BaNzounet 10y ago

Author should provide some before/after code to show how it affected his coding style.

deleted 10y ago

[deleted]

pjmlp 10y ago

No thanks. The last time I could bare not using syntax highlighting I was still on MS-DOS. Since Turbo Pascal 7 (released in 1992), syntax highlighting is a must have on my programming environment. But I understand when we are talking about vim, people prefer an hardcore experience.

yongjik 10y ago
Huh, I thought being "hardcore" about vim meant writing your own syntax highlighting rules. (Which isn't that hard, though vimscript does have some weird quirks.)
- kazinator 10y ago
  Vim's syntax coloring is more powerful than what I have been able to find in other systems. It can handle nested constructs quite well. If you have a situation in which two languages can be embedded in each other. I am using Vim dynamically, calling it out of CGIT. For example: http://www.kylheku.com/cgit/txr/tree/genman.txr http://www.kylheku.com/cgit/txr/tree/genman.txr When you access this file, CGIT runs a syntax highlighting shell script where you can hook in multiple approaches (e.g. based on file suffix). I hacked this script to run Vim via Expect, to load the text and save the HTML with :TOHtml. As you can see, the TXR pattern language and TXR Lisp are nicely separated in the output. The identifiers are colored differently---even in cases when they are the same! Look for a purple (do ...), which is a directive in the TXR pattern language to enclose and evaluate a bunch of Lisp, and green (do ...), which is a totally unrelated construct in TXR Lisp: one of the forms that support explicit partial evaluation. When I'm coding in TXR, Vim is quite accurate in identifying mistakes like string literals not being closed and parentheses not being balanced and such, or various tokens being malformed and whatnot. It can figure it out in spite of levels of nesting. It significantly reduces such errors.
vvpan 10y ago
I don't think that's what "hardcore" means to a vim user. Vim is all about convenience for me.
geocar 10y ago

ncauneia 10y ago

Is disabling syntax highlighting the new standing desk?

jablan 10y ago

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. As one of those programmers who were long ago forced to use no syntax highlighting (because monitors were monochrome), I say no thanks.

stevebmark 10y ago

Not this again "We should remove all color from traffic lights and make people remember which position is what"

taeric 10y ago
Somewhat of a false dichotomy, no? I'm not hurrying up to remove syntax highlighting of source, but I also don't particular care that I don't have it in email snippets. Or in many books. (Of course, now I need to go verify that my books don't actually have some form of typographic trick for source code. Other than tt.) I have gone for a more reserved theme in my editor lately. Currently on solarized again, but probably going back to zenburn soon.
michaelmrose 10y ago
Surely this would make people slow down and pay attention or you know just crash more.
- rosser 10y ago
  There was an article shared here on HN some time back about the guy who got one Dutch town to remove the warning signs on its traffic circles. Accident rates dropped sharply.
- s_kilk 10y ago
  Right, but realistically they'd just crash more and then what's been achieved? Some of us get to feel smug about how the daft plebs aren't hard-core enough to navigate without colored traffic lights?
  - asp_hornet 10y ago
    not OP but I believe that was the point he was making
flukus 10y ago
That would be fun. There are a significant amount of people in my building that don't realize the top light means the elevator is going up and the bottom light means it's going down.

z3t4 10y ago

I only color comments and strings.

satysin 10y ago
Same. Works well for me e.g. http://i.imgur.com/RMrslmu.png http://i.imgur.com/RMrslmu.png
- qznc 10y ago
  Comments and literals (numbers, strings, NULL, etc) here. http://imgur.com/a/kRbhG http://imgur.com/a/kRbhG I tried no-syntax-highlighting for a while, but found that a little bit is nice.

drothlis 10y ago

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. It looks like this: http://david.rothlis.net/code_presentation/distracting_syntax_highlighting/ http://david.rothlis.net/code_presentation/distracting_synta...

Adverblessly 10y ago
To me, all three look bad. Eclipse - no colors for different things, hard to find what I'm looking for (if I compare to the Emacs example, if I was looking at this code trying to figure out what members this class has I'd be looking for brown and finding it much more quickly) Emacs - terrible color scheme, both the brown and the green are too bright, not enough contrast to read. Proposed - all the bold text hurts my eyes and distracts me from everything else. In my crazy theme almost every "thing" has its own color, and it is very easy to find what I want by looking for the right "thing" or combination of things. As an example for where highlighting keywords would help (which is what you mentioned in your post), if I'm looking for "that for loop that does the main logic" I'd look for the place with the small blue blob on the left and a long bright blob to the right (if it was an "if" likely both blobs would be smaller ;)).
maaaats 10y ago
That code is pretty unreadable to begin with, don't think any highlighting or not can save it. But I prefer the Eclipse one, it lets you quickly find the various blocks (public, protected etc.) when skimming through. The proposed scheme is one giant blob.
eikenberry 10y ago
One of the points of syntax highlighting is to create visual patterns you can recognize. Highlighting keywords may help with this. Have you tried disabling keywords highlighting and seeing what difference it makes in reading your code?

the_mitsuhiko 10y ago

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.

foobarian 10y ago
I also don't find the syntax coloring to make a big difference for me. What does though is the semantic feedback/navigation in the IDE. When I joined a Java shop for the first time I was all gung-ho about sticking to my 80x24 terminal and emacs and to heck with the point-and-click crowd who couldn't do their work without a graphical UI. Then my new manager got me to try Eclipse for a week. I humored him and discovered that I was an order of magnitude more productive with Eclipse's semantic features like on-the-fly compile error underlining, code autocomplete, and navigation. It really was a humbling experience.

z0r 10y ago

syntax off, proportional width, (https://twitter.com/rob_pike/status/567476552187641856 https://twitter.com/rob_pike/status/567476552187641856), all code right aligned, ZWS for tabs

qznc 10y ago
Proportional fonts + elastic tab stops [0]. I would love to have this working. Unfortunately, if you really depend on elastic tab stops you break the formatting for everybody who does not use it. [0] http://nickgravgaard.com/elastic-tabstops/ http://nickgravgaard.com/elastic-tabstops/
TurboHaskal 10y ago
- Hey guys we wrote gofmt so all code looks the same. - Great! Now we can finally get things done and stop bikeshedding! - Now about that syntax highlighting of yours...

mseepgood 10y ago

Turning syntax coloring off was the best decision in my career. I have never looked back.

dimman 10y ago
I wouldn't go as far as to say it was my best decision in my career, however it was an important one. I've noticed how I've gone from "click-friendly" GUI's and window managers like Gnome/KDE to Fluxbox, turned syntax highlighting off and at the same time increased my productivity/effectiveness. At first I missed the "fanciness", the new felt boring and pale, however as time passed it made me realize that I'm now focusing on the important things and I'm in control. So yes okay, it's one of my best decisions.
calebm 10y ago
Writing programs all on a single line was the best decision of my career! The enlightenment writing everything on a single line imparted to me was nothing short of an epiphany...
enneff 10y ago
It has definitely been a big improvement to my working life.
pc86 10y ago
You cannot be serious.

douche 10y ago

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.

deleted 10y ago
[deleted]
deleted 10y ago
[deleted]

djhworld 10y ago

I don't agree with the idea whatsoever, but I really like the minimalist design of the authors website.

jowiar 10y ago

I think a large part of the issue with syntax highlighting is that our "standard" for syntax highlighting is rather dumb. A few thoughts: - 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". - I find having lint-errors highlighted provides a similar nudge to the "squiggly-red underline spellcheck". - 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. - Semantic highlighting seems super interesting, but I haven't found a tool that I like yet. 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.

abecedarius 10y ago
> Given 100% control over typography, how would you format [code] to maximize readability There was a book on this, whose title I'm blanking on. Anyone remember? Color wasn't an element, since it was an older book focusing on printing on paper.
- marxidad 10y ago
  Bjarne Stroustrup's C++ book used a proportional font with tabular spacing.
  - abecedarius 10y ago
    So did the book I was thinking of, but it tried more fancier stuff too and iirc reported on some experiments in code reading.
- pYQAJ6Zm 10y ago
  Kinda rings a bell for me, although not from a book, but some LaTeX manual. Maybe this helps: http://tug.ctan.org/macros/latex/contrib/algorithm2e/doc/algorithm2e.pdf http://tug.ctan.org/macros/latex/contrib/algorithm2e/doc/alg...

zvrba 10y ago

Yes, let's use roman numerals too lest we calculate too efficiently and be able to express more complex calculations more easily.

Mr_T_ 10y ago
You mixed it up. Syntax highlighting is like doing arithmetic using colored rods: https://groups.google.com/forum/#!msg/golang-nuts/hJHCAaiL0so/kG3BHV6QFfIJ https://groups.google.com/forum/#!msg/golang-nuts/hJHCAaiL0s... Roman numerals is object-oriented design: https://groups.google.com/d/msg/comp.os.plan9/VUUznNK2t4Q/Ff_uWhnsbwAJ https://groups.google.com/d/msg/comp.os.plan9/VUUznNK2t4Q/Ff...

vbezhenar 10y ago

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.

qznc 10y ago
What I don't understand is that people want to highlight keywords. Bold is a very strong highlight compared to coloring it. However, keywords (if, while, return) can probably be guessed from the indentation alone. There is little need to guide my focus to them even more.
- protomikron 10y ago
  Interesting, for me it is the other way around. I use syntax highlighting (but mostly go with Vim's shipped defaults) and like the keyword highlighting the most. E.g. looking at Python code, it highlights 'def', 'if', 'else', 'elif', 'for', 'while', etc. in orange, function identifiers in cyanish and literals (integer, float, strings) redish (on terminal with blackish background). If I look at code, it helps me to find the beginning of a function and the parts where logic branches (conditions, loops, etc.) start. Some time ago I wrote code without highlighting and although it is obviously possible I found it harder (i.e. it took me more time) to navigate for my eyes. Maybe just using bold or italic would be enough, though. However thinking about it, it might be a nice experiment to highlight identifiers with a unique color (or at least highlight all occurrences of an identifier below the cursor - I think Eclipse does something like that).
- vbezhenar 10y ago
  It allows to quickly understand general structure of the code. Indentation helps too, but it's not enough to quickly distinguish between "for" and "if", for example. Or may be I just got used to it.

eikenberry 10y ago

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.

geocar 10y ago
That's what robertmeta did[1], but when I turned off syntax highlighting I left it off. [1]: https://www.robertmelton.com/2016/04/10/syntax-highlighting-off/ https://www.robertmelton.com/2016/04/10/syntax-highlighting-...
fmueller 10y ago
I turned off syntax highlighting several months ago and never wanted to turn it back on. Scanning the code is now as good as it was before. And understanding und structuring the code got better because I'm no longer distracted by unimportant parts of the code.

jstimpfle 10y ago

> Conditional syntax highlighting 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. I've had this shortcut in my vim configuration for a very long time and I use it frequently: nmap <F11> :if exists("syntax_on") \| syntax off \| else \| syntax enable \| endif \|<newline><C-g> 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. 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.

apetrovic 10y ago

Even better - we should ditch color monitors altogether. You know, to be edgy and different.

rsl7 10y ago
Sure, also let's chuck scrollback in our terminals. What's done is in the past, people.
- vacri 10y ago
  A shiver actually ran up my spine...
zbraniecki 10y ago
My first thought was that if we close our eyes while programming, that will force us to really understand the code we write... As someone put it, it feels like "broscience".
koenigdavidmj 10y ago
I would totally code on an e-ink screen if it was larger than a Kindle.

tambourine_man 10y ago

I worked for years with SimpleText/TextEdit on the Mac (Classic/OS X) and Pico on the server. 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. Then someday I saw a video of someone doing crazy work in Vim. Flying. I had 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. 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.

codepunker 10y ago

Let's not use headlights anymore too... This will force the us to drive more carefully and reduce speed to avoid a potential disaster.

dudzik 10y ago
"The removal of road markings is to be celebrated. We are safer without them" - https://www.theguardian.com/commentisfree/2016/feb/04/removal-road-markings-safer-fewer-accidents-drivers https://www.theguardian.com/commentisfree/2016/feb/04/remova...

k__ 10y ago

I have the feeling most of this isn't a direct problem of syntax highlighting. Most people simply highlight dumb stuff in their code. For example, comments often have a bad contrast and stuff like brackets, curly braces or parathesis have high contrast.

kpil 10y ago

Ok, this thing with young developers going into grandfather-mode is starting to get old. Acknowledge that it's a hipster thing to use vi and fixed gear bikes, and carry on with your life.

bluejekyll 10y ago

In the first few sentences he expressly states why you want highlighting: > I couldn’t skip through the source that fast anymore and it became harder to read 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. 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. 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. I'll never go back; I want my work and job easy, not made harder.

dudzik 10y ago
> which is only his own code by the way Yes, working in a team is definitely a different endeavor. If your teammates or organization aren't open to changes to the style guide then I wouldn't recommend turning syntax highlighting off.
taneq 10y ago
This was my thought - he's altered his style to be more readable without syntax highlighting, which is all well and good for him, but doesn't necessarily translate to it being more readable with syntax highlighting, and so is not necessarily a grand thing for his teammates who still use it.

rcarmo 10y ago

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. But I can see the benefit of forcing you to make your code more readable in general.

CalChris 10y ago

This experiment applies to textbooks as well. 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 syntax highlighting and also no glossy paper. The result was a LOT easier to read. 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.

Animats 10y ago

Syntax highlighting only helps with the easy stuff. It doesn't do anything for std::array<std::shared_ptr<Window>, max_window_count>{}; or s.lines() .map(|bline| UnicodeSegmentation::graphemes(bline, true) .collect::<Vec<&str>>()) .map(|line| wordwrapline(&line, maxline, maxword)) .collect::<Vec<String>>() .join("\n") because nothing there is a language keyword.

wmu 10y ago
A highlighter in Visual Studio is able to distinguish (at least) preprocesor definitions, variables and class names.
jobigoud 10y ago
> because nothing there is a language keyword What editor are you using where the highlighter doesn't identify user-defined types, member functions, namespaces, local variables? Maybe you don't realize it has these capabilities because it's configured to highlight them with the default?

gnuvince 10y ago

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.

iKlsR 10y ago

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. https://i.imgur.com/FHALH2G.png https://i.imgur.com/FHALH2G.png -- or search for Phoenix theme

fatbird 10y ago

I have 2.5 major distinctions made in my syntax highlighting, and it's common to almost all languages for me: 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 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. The base text colour has a small distinction between keywords (darker) and everything else (lighter). 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. 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.

chrismorgan 10y ago
If making comments invisible is at all helpful, they’re being seriously misused. Comments are supposed to explain what’s going on, and thus make things easier. Hiding them should be very counter-productive.
- pYQAJ6Zm 10y ago
  I do the same thing. It’s not as much hiding the comments as making them less attention-grabbing when they are not needed.
- fatbird 10y ago
  As pYQAJ6Zm says: they're not invisible, but when I'm looking at code, they're easily ignored, and when I'm looking at comments, they're easily located. Using solarized dark, the background is Base 03 'bright black' (#002833) and the comments are Base02 'black' made a bit lighter (#004f62). Comments are for holding details: I shouldn't need them to understand code, at least superficially/structurally. But they should be there if I need to drill down on something a bit, and making it so that focusing on that extra detail is easily skipped or applied makes the overall code reading much more fluid.

jug 10y ago

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. 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. 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.

EmmEff 10y ago

FFS, this article is nonsense. If you're not disciplined enough to properly read and review code whether it's colourful or not, syntax highlighting is the least of your worries. Stop deflecting blame for being a poor coder

deleted 10y ago

[deleted]

jack9 10y ago

This seems like old-is-new waxing, reaching for some reason the old way is better. > Initially, turning off syntax highlighting felt weird. I couldn’t skip through the source that fast anymore and it became harder to read. It does, that's the point of syntax highlighting. This isn't a good thing(tm). > 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 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.

jablan 10y ago
You know that vim can syntax-highlight too, right?

twblalock 10y ago

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. 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. 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.

dinhnv 10y ago

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.

Yaggo 10y ago

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.

bbarn 10y ago

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. 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.

Kareeeeem 10y ago

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. So I use this. https://github.com/Kareeeeem/vim-walou https://github.com/Kareeeeem/vim-walou There's more stuff like it but I wanted to pick my own gray values and dislike pure white on pure black.

barat 10y ago

Is there any example for this so-called conditional highlighting that we could take a look at ?

yitchelle 10y ago

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. 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.

draw_down 10y ago

No, no, no.

Rudism 10y ago

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. 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.