13 tips to show code on-screen

Eventually a developer will have to show some code. Whether it’s during a demo on the trendiest technology, during a TDD Kata, or even during one’s first talk at Devoxx.

During these events, it is of utmost importance to keep in mind the reader’s reading comfort. Whether you are sitting 30 centimeters from your screens, sitting in the back of a lecture hall, or when looking at the code projected on a flat screen in a South-oriented meeting room, viewing conditions will be different.

Code display also includes commands on a terminal. I often see a presenter showing his terminal. It is often harder to understand what is happening on the screen if I’m at the back of the room.

Thereader’s comfort above all

AGAIN: viewing conditions aren’t the same when you’re working alone and when you look at someone’s code at a conference.

1. Use a bright background

Most content on the Internet — such as Wikipedia, social media and documents — are presented with a black text on a bright background. But the majority of developers use a black background-theme like Darkula or Anthracite. Where does this discrepancy comes from ?

Dark theme is often liked by younger developers. They still have good eyes and spend most of their day in front of the screen. In a dark office, the screen becomes the main source of light, and working for a long period of time on a bright screen causes eye strain. In that case, a dark background with a bright font (but not white, to limit the contrast) is a really comfortable situation for the eyes. From my experience, the most experienced developers will code on a bright background most of the time.

If the former is more relaxing on a long period work and in some other particular situation, it is more wearisome most of the time than the latter.

White stimulates all three types of color sensitive visual receptors in the human eye in equal amounts. It causes the eye to focus by tightening the iris. Since the eye is focused, dark letter forms on light backgrounds are easier to read. When using a dark background with strong light letter forms, the iris opens to allow more light in, but that causes letter forms to blur.

Two different paragraphs

A dark background is rarely adapted to large screens or overhead projectors. Your viewers won’t all be in front of the screen and will be dazzled by any reflection on a dark screen. If you sometime code on your sunny patio, you know that using a dark screen is impossible in that situation.

For the record, the human eye serves two functions : scanning and reading . It will read a paragraph, which means going through all the words to understand the general meaning. But it will scan a title while seeing the words as a whole.

As this article on UXMovement says, it’s easier to scan a short text with a white font on a colored background and it is easier to read a text on a bright background. In a presentation slide, this is a way to adapt the style to your content.

2. Increase the font size.

And keep on doing it. I believe that the right size is under 20 lines on the screen . It seems huge, but keep in mind those attendees in the back of the room.

For example, take a look at the screen in this presentation , by Thomas Pierrain and Bruno Boucard at Tech Conference bdx.io :

The camera is right at the bottom of the stage. You can easily imagine how hard it would be for someone sitting at the 10th row to read something on that screen.

This is the main rule I follow :

The text is still readable if I am two meters away from my laptop screen .

Line length should be under screen width. If you are using an IDE, I recommend you to use the « Presentation mode » to save space by hiding all the toolbars and menus.

3. Use a simple syntax highlighting style or don’t use any.

A syntax highlighting style lets the viewer recognize, at a first glance, all of the important parts in the syntax. When selecting colors for the syntax highlighting, remember the color scheme choices discussed above and ensure the text is clearly visible.

It is better not to have any syntax highlighting than having a bad one.

A colorblind anecdote : I had customized the highlighting style of my IDE and had set the compilation errors to be underlined green instead of red. As a result, my colleagues who were coding on my computer during a coding-dojo took a long time to realize that they had written a non-compiling code.

Here is an example you shouldn’t follow :

• Dark red on a black background is unreadable
• Bright orange on a white background is unreadable
• Blue on a black background is illegible for a colorblind

For a slide presentation, use carbon.now ( as an easy alternative to create your code extracts for a presentation).

Comfort in the code navigation

In the case of a live-coding, losing the sight of the presenter’s cursor is a really common thing, especially in the case where a lot of refactoring is happening on the screen in a small period of time. To help the viewer locate your cursor in your code, here are some tips :

4. Show the line numbers.

With the help of the line numbers, you can easily describe what you are doing to help your viewers coming back into the presentation if they lost track.

The condition on ligne 49 is the same than the one on line 39, see ?

5. Highlight the current line

In IDEs and vim, you can highlight the line on which your cursor currently is. It makes it easy for the viewers to see which line is being modified.

6. Use a block cursor instead of a line cursor.

By using a block caret with a low blink rate, even the drowsy viewers will be able to easily jump back into the presentation of your refactoring.

7. Allow the cursor to position after the end of a line

As its name suggests, this option allows the cursor to move beyond the end of a code line.

I have a mixed feeling about this option. On the one hand, it allows a fluid cursor vertical movement in the code. On the other hand, this is a disruptive option in coding-dojos because the attending members are used to right to jump to the next line. It also means that as a live-coder, you’ll have to relearn how to navigate through your code.

A code presentation… is still a presentation.

You probably have done a presentation or a thesis defense in your studies or your working life. In that case, much like in the case of a code presentation during a conference, use the 3P rule. You’ll need:

• Preparation
• Preparation
• Preparation

8. Plan your demonstration.

Make a list of every important steps, and keep it close at any time during the demo. Thus you will be able to come back to it if you have any doubts.

9. Version your code

You are a developer. There is a big probability that you are able to use git , so take advantage of that. Version your code, and check that you can go back to a working version at any time. If you are using an event store, it is also very important to version it. There are many guides that explain how you can do (for example http://programmaticallyspeaking.com/code-demo-using-git.html ). Ease your backup workflow by using aliases and tags.

10. If you cannot ensure a working code, you have other options.

If you are creating an Android/Unity app that use augmented reality by scrapping the data from your custom API, there are dozens of different ways your demo can crash (Internet is not working, your phone doesn’t have enough battery etc . . .). In those situations where the versioning of your application code doesn’t allow you to cover every problems that can happen, you’ll have to keep a video of your working demo, it’s better than having nothing to show and being stuck with a « It should have worked there ». Listen to experienced speakers , those situations where nothing works happens more often than not.

11. Avoid distractions

We have all seen a speaker receive a tweet during a presentation or even an email or a funny Slack message. The best case scenario being that the message is banal and not interesting. Most of the times you’ll unconsciously read the message and break your thoughts flow. Depending on your comfort, you can keep going as if nothing had happened, or you can lose the flow on the conversation and start stuttering. In rare cases that have already happened you can get a nude-pic from the Tinder conquest you had last week end.

There is little chance that you’ll need either Facebook or Twitter during your presentation. Close all your social networks tabs and apps before starting and keep off the troubles. Macbooks have had an option to disable the notifications for years, use it.

12. Disable sleep-mode and standby-mode

That’s one surprisingly common mistake I see every once in a while. There’s no need for sleep mode, and it can mess-up your presentation and other recording tools.

13. Work on your pace.

Depending on your presentation’s theme, you can speed up or slow down with ease. It’s up to you to use more Ctrl + Z and re-do all your manipulation if you feel that you went too fast for the viewers. The use of a template or a copy-paste is sometimes appropriate, sometimes it is not. Detect the key-steps of your presentation to speed up those who doesn’t have much value or to slow down on those who are critical to your presentation.

I’d love to hear what tips you use, feel free to add your own tips in the comment section.

Some sources : Stack-Overflow and UX matters and UX-movement