Programmers spend a lot more time reading code than writing code. Making code easier to read will allow you to work faster and better.Tips to improve code readability:<ul><li>Use a font designed for programming (monospace fonts are good)</li><li>Auto-fold functions when opening files to avoid being overwhelmed</li><li>Give descriptive names to variables and functions</li><li>Use a light color scheme</li><li>Lower the brightness and increase the contrast of your display</li></ul>

Make code easier to read

As a professional programmer, I'm reading and writing code on a daily basis.
I'm working on new projects, doing code reviews, working with legacy code, reading through documentation etc.
Based on my own experience and that of colleagues, being a programmer often involves a lot more reading than actually writing code.Whether it's your own code or that of others, when you open a file you have to take it all in.
You need to wrap your head around what's going on, before you're able to write your code, do your thing.Having to deal with code almost every day, it's important to find ways to make this process easy.
To try and reduce the cognitive load it puts on your brain as much as possible.Making code easier to read will allow you to work faster and better, and also improve your mental state and mood.<BLOCKQUOTE>In cognitive psychology, cognitive load refers to the total amount of mental effort being used in the working memory - <a href="https://en.wikipedia.org/wiki/Cognitive_load" dir="ltr">wikipedia</a></BLOCKQUOTE>Today I want to share some techniques that can help you reduce cognitive load while coding.
In contrast to some recent advocates of "visual debt", I won't talk about stripping away pieces of your codebase.
We'll look purely into the visual aspect: what makes code hard to read and reason about, and how to make it easier.<img src="https://cdn4.buysellads.net/uu/1/87054/1618852249-Carbon_Ads-Stack_Overflow-Logo-260x200-V2.png" alt="ads via Carbon" height="100" width="130"><h2> Fonts and spacing</h2>Fonts have an influence on our mood.
The <a href="https://crew.co/blog/the-psychology-of-fonts/" dir="ltr">people at Crew</a> wrote an interesting piece about how fonts make us feel.
The font you choose has a big impact on how much load is put on your brain to process the text on your screen.
It's not just the font by the way, but also its size, line height and letter spacing plays a role.Typography itself is a topic books are written about.
I encourage you to think about your current font choice, and how it influences the way you read code.Here's a comparison between a not-so-good and better font configuration, in my experience.<img src="https://stitcher.io/resources/img/blog/cognitive-load/aestetics-1.png" srcset="https://stitcher.io/resources/img/blog/cognitive-load/aestetics-1-1341x1442.png 1341w, https://stitcher.io/resources/img/blog/cognitive-load/aestetics-1-670x720.png 670w, https://stitcher.io/resources/img/blog/cognitive-load/aestetics-1-1161x1249.png 1161w, https://stitcher.io/resources/img/blog/cognitive-load/aestetics-1-1500x1614.png 1500w, https://stitcher.io/resources/img/blog/cognitive-load/aestetics-1-948x1020.png 948w" alt="" width="750" height="807"><img src="https://stitcher.io/resources/img/blog/cognitive-load/aestetics-2.png" srcset="https://stitcher.io/resources/img/blog/cognitive-load/aestetics-2-670x726.png 670w, https://stitcher.io/resources/img/blog/cognitive-load/aestetics-2-1341x1453.png 1341w, https://stitcher.io/resources/img/blog/cognitive-load/aestetics-2-1161x1258.png 1161w, https://stitcher.io/resources/img/blog/cognitive-load/aestetics-2-1500x1626.png 1500w, https://stitcher.io/resources/img/blog/cognitive-load/aestetics-2-948x1027.png 948w" alt="" width="750" height="812"><h2> Folding</h2>Ever worked with a controller providing some CRUD actions?
A class with a few methods?
Folding your method bodies by default gives you a much clearer overview of the class when opening a file.
It makes it easier to decide where you want to go to, instead of scrolling and searching.
Take a look at the following example.<img src="https://stitcher.io/resources/img/blog/cognitive-load/aestetics-3.png" srcset="https://stitcher.io/resources/img/blog/cognitive-load/aestetics-3-948x815.png 948w, https://stitcher.io/resources/img/blog/cognitive-load/aestetics-3-1161x999.png 1161w, https://stitcher.io/resources/img/blog/cognitive-load/aestetics-3-1341x1154.png 1341w, https://stitcher.io/resources/img/blog/cognitive-load/aestetics-3-670x576.png 670w, https://stitcher.io/resources/img/blog/cognitive-load/aestetics-3-1500x1291.png 1500w" alt="" width="750" height="645">IDEs like IntelliJ can fold code by default: <code dir="ltr">Settings &gt; Editor &gt; General &gt; Code Folding</code>.
I was a bit hesitant to enable it by default, but I can assure you this is an amazing feature once you're used to it.It's also more convenient compared to the file structure navigator many IDEs and editors provide.
This approach allows you to see the visual structure, color and indentation of the class.You'll probably want to learn the keybinds associated with folding too. On Mac with IntelliJ, these are the defaults: <code dir="ltr">⌘⇧+</code>, <code dir="ltr">⌘⇧-</code>, <code dir="ltr">⌘+</code> and <code dir="ltr">⌘-</code>.<h2> Documentation</h2>Documentation and comments are good tool to clarify what code actually does.
Furthermore, some languages and IDEs rely on comment meta data to provide proper static analysis.
We shouldn't overdo it though: docblocks and comments often state the obvious things, which are already known by reading the code.After several years of programming, I can safely say that about 80-90% of comments are redundant.
They should be removed to clear visual overload, but you also need to provide something in their place:<UL><LI>Clear naming of methods, variables, constants, etc.</LI><LI>Use proper type annotations and definitions</LI></UL>Self documented code is better than relying on comments.
My rule of thumb when adding a comment is asking the following question:
"Does this comment actually add more information than already available through the code?".
If the answer is no, the comment shouldn't be there.Removing these comment frees up your code, giving you visual "space to breath".<h2> Naming things</h2>Another important thing to keep in mind: how to name things?
It's better to give a variable a longer, descriptive name; rather than make them as short as possible.Short, cryptic names make sense at the moment of writing the code;
but even a few days after you've written them, they already become vague and meaningless.Better to write a little more, than to read ten times as much to understand what you've written in the past.Here are a few examples from an project of mine:<UL><LI>I renamed <code dir="ltr">createPage()</code> to <code dir="ltr">createPaginatedPage()</code>.</LI><LI>
<code dir="ltr">$process</code> became <code dir="ltr">$pageRenderProcess</code>.</LI><LI>
<code dir="ltr">testStitcher()</code> changed to multiple methods, one of which called <code dir="ltr">test_stitch_multiple_routes()</code>.</LI></UL><h2> Colours</h2>This might be a sensitive topic for many people;
though I want to ask you to give me the benefit of the doubt for a minute.
We all like our dark, cool looking colour schemes, but there's a problem with them.Research shows that the human eye is better equipped to read dark text on light backgrounds,
than the other way around. Back in the 80's, when personal computing was growing in popularity,
a guy called Etienne Grandjean did an <a href="https://dl.acm.org/citation.cfm?id=578434" dir="ltr">extensive study</a>
on how text is best read on screens.It turned out that light colour schemes are, for almost all people, the better choice.Now your first thought might be that light colour schemes actually hurt your eyes,
but this has more to do with the brightness of your screen, than the colour scheme itself.It's true that a light colour scheme can cause headaches and painful eyes if you don't turn down the brightness of your screen.
On the other hand, a less bright screen in combination with a light colour scheme will put less load on your eyes,
which makes reading code for long periods of time less exhaustive.I can say what I want of course,
but the best thing I could do is challenge you to a one-week tryout.
I've challenged many programmers before, and most of them were actually convinced of a light theme after a few days.It's up to you! Here's how my code looks like these days:<img src="https://stitcher.io/resources/img/blog/cognitive-load/aestetics-4.png" srcset="https://stitcher.io/resources/img/blog/cognitive-load/aestetics-4-670x590.png 670w, https://stitcher.io/resources/img/blog/cognitive-load/aestetics-4-1341x1180.png 1341w, https://stitcher.io/resources/img/blog/cognitive-load/aestetics-4-1499x1320.png 1499w, https://stitcher.io/resources/img/blog/cognitive-load/aestetics-4-948x834.png 948w, https://stitcher.io/resources/img/blog/cognitive-load/aestetics-4-1161x1022.png 1161w" alt="" width="750" height="660">Be sure to let me know how the challenge went!
You can reach me on <a href="https://twitter.com/brendt_gd" dir="ltr">Twitter</a> or via <a href="mailto:brendt@stitcher.io" dir="ltr">e-mail</a>.The points I listed today have almost nothing to do with how you write real code (programming logic, patterns used, etc.).
But they have an impact on the cognitive load put on your brain day by day.They take away some of the pain points when writing code.
They allow you to enjoy programming more.

As programmers we're almost always reading code. There are a lot of things we can do to make this easier.

personaldevelopment

Personal Development

communication

Communication

As a professional programmer, I'm reading and writing code on a daily basis. I'm working on new projects, doing code reviews, working with legacy code, reading through documentation etc. Based on my own experience and that of colleagues, being a programmer often involves a lot more reading than actually writing code.

Whether it's your own code or that of others, when you open a file you have to take it all in. You need to wrap your head around what's going on, before you're able to write your code, do your thing.

Having to deal with code almost every day, it's important to find ways to make this process easy. To try and reduce the cognitive load it puts on your brain as much as possible.

Making code easier to read will allow you to work faster and better, and also improve your mental state and mood.

In cognitive psychology, cognitive load refers to the total amount of mental effort being used in the working memory - <a href="https://en.wikipedia.org/wiki/Cognitive_load">wikipedia </a>

Today I want to share some techniques that can help you reduce cognitive load while coding. In contrast to some recent advocates of "visual debt", I won't talk about stripping away pieces of your codebase. We'll look purely into the visual aspect: what makes code hard to read and reason about, and how to make it easier.

Fonts have an influence on our mood. The <a href="https://crew.co/blog/the-psychology-of-fonts/">people at Crew </a>wrote an interesting piece about how fonts make us feel. The font you choose has a big impact on how much load is put on your brain to process the text on your screen. It's not just the font by the way, but also its size, line height and letter spacing plays a role.

Typography itself is a topic books are written about. I encourage you to think about your current font choice, and how it influences the way you read code.

Here's a comparison between a not-so-good and better font configuration, in my experience.

Ever worked with a controller providing some CRUD actions? A class with a few methods? Folding your method bodies by default gives you a much clearer overview of the class when opening a file. It makes it easier to decide where you want to go to, instead of scrolling and searching. Take a look at the following example.

IDEs like IntelliJ can fold code by default: <code>Settings > Editor > General > Code Folding </code>. I was a bit hesitant to enable it by default, but I can assure you this is an amazing feature once you're used to it.

It's also more convenient compared to the file structure navigator many IDEs and editors provide. This approach allows you to see the visual structure, color and indentation of the class.

You'll probably want to learn the keybinds associated with folding too. On Mac with IntelliJ, these are the defaults: <code>⌘⇧+ </code>, <code>⌘⇧- </code>, <code>⌘+ </code>and <code>⌘- </code>.

Documentation and comments are good tool to clarify what code actually does. Furthermore, some languages and IDEs rely on comment meta data to provide proper static analysis. We shouldn't overdo it though: docblocks and comments often state the obvious things, which are already known by reading the code.

After several years of programming, I can safely say that about 80-90% of comments are redundant. They should be removed to clear visual overload, but you also need to provide something in their place:

<ul><li>Clear naming of methods, variables, constants, etc. </li><li>Use proper type annotations and definitions </li> </ul>

Self documented code is better than relying on comments. My rule of thumb when adding a comment is asking the following question: "Does this comment actually add more information than already available through the code?". If the answer is no, the comment shouldn't be there.

Removing these comment frees up your code, giving you visual "space to breath".

Another important thing to keep in mind: how to name things? It's better to give a variable a longer, descriptive name; rather than make them as short as possible.

Short, cryptic names make sense at the moment of writing the code; but even a few days after you've written them, they already become vague and meaningless.

Better to write a little more, than to read ten times as much to understand what you've written in the past.

Here are a few examples from an project of mine:

<ul><li>I renamed <code>createPage() </code>to <code>createPaginatedPage() </code>. </li><li><code>$process </code>became <code>$pageRenderProcess </code>. </li><li><code>testStitcher() </code>changed to multiple methods, one of which called <code>test_stitch_multiple_routes() </code>. </li> </ul>

This might be a sensitive topic for many people; though I want to ask you to give me the benefit of the doubt for a minute. We all like our dark, cool looking colour schemes, but there's a problem with them.

Research shows that the human eye is better equipped to read dark text on light backgrounds, than the other way around. Back in the 80's, when personal computing was growing in popularity, a guy called Etienne Grandjean did an <a href="https://dl.acm.org/citation.cfm?id=578434">extensive study </a>on how text is best read on screens.

It turned out that light colour schemes are, for almost all people, the better choice.

Now your first thought might be that light colour schemes actually hurt your eyes, but this has more to do with the brightness of your screen, than the colour scheme itself.

It's true that a light colour scheme can cause headaches and painful eyes if you don't turn down the brightness of your screen. On the other hand, a less bright screen in combination with a light colour scheme will put less load on your eyes, which makes reading code for long periods of time less exhaustive.

I can say what I want of course, but the best thing I could do is challenge you to a one-week tryout. I've challenged many programmers before, and most of them were actually convinced of a light theme after a few days.

It's up to you! Here's how my code looks like these days:

Be sure to let me know how the challenge went! You can reach me on <a href="https://twitter.com/brendt_gd">Twitter </a>or via <a href="mailto:brendt@stitcher.io">e-mail </a>.

The points I listed today have almost nothing to do with how you write real code (programming logic, patterns used, etc.). But they have an impact on the cognitive load put on your brain day by day.

They take away some of the pain points when writing code. They allow you to enjoy programming more.

A programmer's cognitive load

Make code easier to read

Ovidiu Podariu (Tech)'s ideas are part of this journey:

Related collections

Similar ideas