Yesterday I suggested that you not use syntax coloring in presenting code at talks and in books. Some folks to issue with my proposal and raised valid points. Let's talk a little more about colors in code samples.

For people doing live coding demos, syntax coloring is fine. I can see where the presenter is typing and that focuses me on the new code. For people presenting slides, I prefer a method used by many (including Apple in their WWDC slides). I use a single accent color to draw attention to the code I'm discussing.

Some presenters and authors prefer line numbers. Some prefer labeled markers. In early books, I animated code builds using the Hype app. Currently, I use the following scheme:

In presentation slides, I have a white text on a black background and I highlight new code by presenting it as a yellow text that is easily distinguished from the white.

In books, I'm using a white background with a dark blue font for existing code and a red font for new code. I also use other colors for comments and for console/playground response. I was using black for console and playground response but when I removed the border lines from my code samples this code looked too similar to my main text.

This brings me to the most common objection I received: using colors to distinguish between new and existing code might mean that some of my readers will have difficulty distinguishing colors.

A few months ago Brian Hogan suggested I use the app Color Oracle to view my books as people with three different types of color blindness might see them. That has been helpful in choosing and tuning my code colors.

Many people misread my post as advocating that I use no color at all.

I was and am advocating color that helps focus the reader or audience member's attention on what you need them to see.

As a simple example, suppose I've been talking about an enumeration in Swift named EnumExample. And suppose that I want to back it with an Int. Then I would present a slide that shows the enum's declaration and body in my standard color with just the ": Int" presented in the accent color. That is the only thing that I am changing and I want to direct your attention at what it is I'm talking about now.

Scott Stevenson made a wonderful analogy that he thinks that coloring code helps readers in the same way that color on a transit map helps you navigate a complicated system. He separates presentations from books because in books a reader has plenty of time to go back and reread. He likes syntax coloring because it helps you parse the code.

Kim and I spent a week in Tokyo using the JR lines to get from one place to another. As Scott says, it's very helpful that the line which is green on the map also has green on the signs that direct us through a busy station to the tracks on which the lines run.

The JR system doesn't know which line each person wants to take so they have colors for each line.

For us, however, when we need to get somewhere on the Yamanote line, all of the other colors are competing with the one thing we need to see on the map and the one color we need to see in the station.

It's kind of like old fashioned exhibits in science museums where all of the colors are on the screen for the different body parts but when you press the button for veins, the background dims and the veins are lit up lighter.

Perhaps I should use syntax coloring and modify the opacity of what I'm showing.

Then again, my designer will have a thing or two to say about this. Every time I introduce too much color or decorate my text too much she quietly lets me know I need to pull things back a bit.

I'm currently using the "highlight new code" style in my presentations and books (for example, he says while shamelessly marketing, A Swift Kickstart).

Let me know what you think.