Visual Studio Code: 6 settings to light up your code screenshots.
Tags: documentation, tipstricks, vscode, code
Published: 2017-07-28 17:13:49

---
title: "Visual Studio Code: 6 settings to light up your code screenshots."
published: true
description: Tips and tricks for creating great code screenshots to use in your documentation. 
tags: documentation, tips & tricks, vscode, code
---

Use VS Code? Take screenshots of your code often? Here's a simple tip that will help you get clean, crisp screenshots of your code every time. 

![](https://github.com/AndrewJByrne/assets/blob/master/i/practical-dev/1/pablo-11.png?raw=true)

Whenever I need to explain something to someone, I inevitably head straight for the whiteboard or napkin to tease out a visualization of what I am trying to convey. I can't draw to save my life but that's not important. I draw *enough* to get my point across. My current role as a course creator/instructor reinforces my belief that I can deliver so much more knowledge by carefully selecting the right communication medium - words, a video, a picture, a screencast or even code itself. 

To illustrate the problem I want to solve here, let's highlight it with the following screenshot... 

![annotated screenshot](https://github.com/AndrewJByrne/assets/blob/master/i/practical-dev/1/annotate-screen2.png?raw=true)

This is my typical setup in VSCode when I'm writing code. As you can see, I've tailored the editor using the power of VS Code Settings for my own needs. However, when I want to grab a screenshot of my code there is way too much scaffolding in the way. I will solve the following issues in this article by tweaking my VS Code settings. 

* Font is too small
* Too much noise on screen in terms of scaffolding

> Why VS Code? Recently I published my first course on edX, [Writing Professional Code](https://www.edx.org/course/writing-professional-code-microsoft-dev275x). In this course I talk about source control, how to make your code more readable, unit testing and more. My editor of choice was Visual Studio Code, primarily because it is cross-platform and free. Yes, I work for Microsoft but I did feel VS Code was the right tool for the job at hand. There's so much to love about VS Code and perhaps someday I'll pen my own love letter about it. Ben Halpern wrote a [great post recently on why he switched to Visual Studio Code](https://dev.to/ben/why-i-switched-from-atom-to-visual-studio-code)  and that should give you some independent insight into this editor choice. 

Let me walk you through each numbered item I showed in the last screenshot, explain what it does and why I use it and then how I changed each item for the purposes of making decent screenshots. But first ...

## Did you know?

Visual Studio Code has very powerful settings, customization and extensibility features that really help you make the editing experience suit your individual needs. In terms of settings, everything that you can modify is available to you in a simple **settings.json** file. Here's a glimpse of my settings.json on my machine. 

![](https://github.com/AndrewJByrne/assets/blob/master/i/practical-dev/1/settings-json2.png?raw=true) 

You get to this file in VS Code with **Ctrl+,** or **⌘,** on macOS (note the comma is part of the command!). As you can see, defaults and rich comments are supplied for every setting. With every monthly refresh from the VS Code team, available settings are tweaked to make sure developers get the most out of these customizations.  In the top right of the preceding screenshot, we see that settings can be scoped to your workspace or to you, the user. So, my typical settings that are available as soon as I open VS Code are my *User Settings*. The settings that I  change just for the current open workspace are called my *Workspace Settings*.

> I'm going to take advantage of the Workspace Settings in this article because the  changes I make to settings in order to clean up my editor and take a nice screenshot are temporary setting changes for the open workspace. 

So, now that we know where settings live, let's tweak them to show how they impact what we see. 

## 1. Honey, I Grew the Font!

The first issue I want to tackle is  that the default font size I use for coding is  not easy on the eye when viewed as part of a screenshot. As the first screenshot earlier shows, the font is too small to read. Zoom level is controlled by the setting **window.zoomlevel**. I set it in workspace settings to `"window.zoomLevel": 2` 

This gives me the following improvement in font size.

![](https://github.com/AndrewJByrne/assets/blob/master/i/practical-dev/1/setting-1-1.png?raw=true)

## 2. Remove the Lens

*CodeLens* is a really useful feature in the Visual Studio family of products. It basically gives you contextual information inline in your editor about the code you are currently looking at. In the first screenshot I showed in this article you can see CodeLens at work showing us how many references there exist to a field, method, constructors and so on. Great information to have right in front of you while coding, but not so useful when taking a screenshot, unless of course you are talking about those references or other contextual information. I eliminate them from my screenshots by setting `"editor.codeLens": false` in my workspace settings and saving the changes.  Once that's done, I get the following with CodeLens markers removed ...

![](https://github.com/AndrewJByrne/assets/blob/master/i/practical-dev/1/setting-2.png?raw=true) 

## 3. White Walkers Be Gone!

Only kidding, I actually mean removing whitespace rendering but that's oh so much more boring. Those little dots you see in my screenshot are rendered whitespace that help at times to see how everything is aligned. Screenshots and screencasts? I don't see the value of these dots, so let's remove them up by setting `"editor.renderWhitespace": "none"` and I end up with ...

![](https://github.com/AndrewJByrne/assets/blob/master/i/practical-dev/1/setting-3-2.png?raw=true) 

## 4. Lose the Highlight 

I must admit, I struggle with this one a little. The feature I'm talking about, and shown in the first screenshot with the number 4, is the light-gray highlight that surrounds the current line in the editor. For screenshots it feels noisy to me, so I like to remove it. For screencasts it doesn't hurt and might help the viewer to see you move from line to line more easily. That said, I'm removing it here with the setting `"editor.renderLineHighlight": "none"` and that leaves me with the following subtle update ...

![](https://github.com/AndrewJByrne/assets/blob/master/i/practical-dev/1/setting-4.png?raw=true) 

## 5. Indent Guides? Computer says, Nah!

Indent guides (item 5 in the first screenshot) help me keep tidy. Now, full disclosure, I've never left them off for long periods and watched my code crumble to a mess and I doubt that will happen. Editors are too sophisticated to let me screw up badly and I've perfected a style at this point such that I can see quickly when I am producing smelly code and structure. However, I don't mind the indent guides being on, except when making screenshots and screencasts. So, with the magic of `"editor.renderIndentGuides": false` I get to the following happy place:

![](https://github.com/AndrewJByrne/assets/blob/master/i/practical-dev/1/setting-5.png?raw=true) 

## 6. Column, dismissed!

Instead of wrapping my code automatically after a certain width, I enable a column marker at column 80 and just keep an eye on my code to make sure I don't go wild and flow past that width too much. 80 is historical and arbitrary at this point but it does mean most of my code fits neatly into blog posts without too much horizontal scrolling. When demonstrating code and showing screenshots, I don't think that marker adds value and may, in fact, disctract. I, therefore, remove it when taking screenshots  with the setting `"editor.rulers": []` which removes all ruler definitions (empty array). That gives me the final clean state as follows:

![](https://github.com/AndrewJByrne/assets/blob/master/i/practical-dev/1/setting-6.png?raw=true) 



*"But wait Andrew"*, I hear you say, *"what about item 7 in your first screenshot"*? 

Good question, my friend. Item 7 is showing line numbers. Line numbers are great when describing code, for example, in code reviews. I also use them in screenshots and screencasts. They are tucked neatly over to the left of all the action and comes in handy. So, I'm leaving these enabled. Besides, I promised you six settings *changes*, and six is what you get :-) 

## Finita La Musica

And there you have it, six settings that are easy to set in VS Code when you want to start taking nice screenshots of your code without the noise of some of your daily scaffolding. Here they all are grouped together so you can more easily copy and paste. 

```javascript
"window.zoomLevel": 2,
"editor.codeLens": false,
"editor.renderWhitespace": "none",
"editor.renderLineHighlight": "none",
"editor.renderIndentGuides": false,
"editor.rulers": []
```

I hope you found this tip useful and would love to hear about settings tweaks or other efficiencies you use in your VS Code setup. 

Until the next time, here's  an animation of all the changes mentioned in this  article happening in front of your eyes :-)

![](https://github.com/AndrewJByrne/assets/blob/master/i/practical-dev/1/changes.gif?raw=true)