<p>Using the English language, given two sentences that say the same thing, what makes one more readable than the other? Usually terseness while retaining clarity and removing ambiguity.</p>

<p>The exact same things make code more readable. Remove everything that doesn't add anything, but don't remove things that do add information. And avoid ambiguity.</p>

<p>In code, we have the advantage that we can reuse similar pieces of text and replace specific values within them. If only we could do that with books, we could save a small rainforest.</p>

<p>On top of terseness, we have good use of punctuation and spacing. Ever tried to read a blog piece where there are no paragraphs whatsoever? That's what it's like reading code that isn't neatly spaced out.</p>

<p>The psychology of this is simple. Your brain receives all sorts of hints as to what it's reading. Try taking a long piece of text and printing it out (with a serif font) without paragraphs, then without periods and commas, or maybe switch punctuation marks (? => ., ! => :, etc), then in a sans-serif font.</p>

<p>You'll quickly see how much you rely on your brain's instincts when you're reading. Code is exactly the same. And herein lies a problem, because some things are certainly subjective. Or rather they are a matter of habit.</p>

<p>If you're used to seeing underscores preceding member variables, then you move to a company where they don't do that, your brain will still expect the same hints and it will be harder to read. But to change it would mess up everybody else in the team. It would be like moving to Spain and telling them to stop using the preceding <a href="http://en.wikipedia.org/wiki/Inverted_question_and_exclamation_marks">inverse-question mark</a> because it throws you off.</p>

<p>Design patterns are a similar thing. If everyone knows what a Builder Pattern does, then adding Builder to a class name gives everyone a lot of information. But if I have my own Bracksfort Pattern, that information only helps me, at least until other people start to ask me, or I document it and get the community to buy into it.</p>

CC BY-SA 3.0
2013-04-12T19:31:29.850Z
@what: Well, yes. If I took a piece of English text and reduced all the nouns and adjectives to one letter, you might struggle to read that too.
pdr
CC BY-SA 3.0
2013-04-19T08:03:54.720Z
@what This is what I was going for! I assume that not only the length is important for "readability" but also what the identifier says, so its semantics (Compare the old "#define TRUE FALSE // Happy Debugging" Joke). I found that for example F# Code often reads like maths and is completely unreadable, yet very reasonable. This is mostly due to its abstractness and very concise identifiers.
cessor
CC BY-SA 3.0
2013-04-09T11:58:37.530Z
2013-04-09T12:24:35.293Z
pdr
<p>This is my current area of research (I'm a Ph.D. student in computer science and cognitive science). Like you said, there are a large number of readability/complexity metrics, but very little research trying to quantify what makes a piece of code <strong>psychologically</strong> complex. For more information on <em>qualitative</em> studies and models, I'd highly recommend the 2001 book <a href="http://rads.stackoverflow.com/amzn/click/1852332530">Software Design: Cognitive Aspects</a>.</p>

<p>I've been running some experiments recently with the goal of developing a cognitive model that can "read" code like a human. The inspiration for my model largely comes from <a href="http://www.sciencedirect.com/science/article/pii/095058499591491H">a 1995 paper by Simon Cant et. al.</a>. In the paper, they lay down an (incomplete) foundation for a mathematical model that "chunks" small blocks of code into memory and "traces" to other parts of the program in order to resolve dependencies. I have a workshop paper titled "Cognitive architectures: a way forward for the psychology of programming" that suggests we may be able to built such a model on top of a cognitive architecture like ACT-R.</p>

<p>I'm currently writing up the results of one of my experiments. Once it's ready, I'll be posting about it on my blog (synesthesiam.com). In short, we had programmers of all different experience levels predict the output of 10 Python programs (each program had 2 or 3 versions). Some of them did the experiment in front of an eye-tracker, which will be another paper someday (hopefully) soon. The rest were from Mechanical Turk, and we observed interesting speed/accuracy differences that were not always in favor of the more experienced programmers.</p>

CC BY-SA 4.0
2021-07-31T00:36:15.953Z
I think this needs a followup that takes into consideration language conventions and the effects of readability from a convention standpoint. Even more interesting would be focusing on C-Syntax languages like Java, C#, and JavaScript which have more syntax intended to delineate blocks which helps with chunking. What happens when you start removing that syntax, or using it in unconventional ways? For instance by chasing "Fewer lines is better".
Douglas Gaskell
CC BY-SA 3.0
2013-04-19T00:56:42.497Z
Welcome to the site. Thanks for sharing your expertise.
Jeromy Anglim
CC BY-SA 3.0
2013-04-19T07:59:55.780Z
Hello user2925, thank you for your answer. I am too planning an experiment right now and I was wondering whether you could share some more of your experiences?
cessor
CC BY-SA 3.0
2013-04-19T14:58:31.463Z
Hi @cessor. I'd be happy to share my experiences. What kind of experiment are you planning?
Michael Hansen
CC BY-SA 3.0
2013-04-19T20:55:13.687Z
@MichaelHansen I think it would be best to discuss this in private! Could you send me an email to the address in my profile? :)
cessor
CC BY-SA 3.0
2013-04-22T13:52:40.573Z
**Update**: I posted a paper about the experiment mentioned in my answer [on arXiv](http://arxiv.org/abs/1304.5257).
Michael Hansen
CC BY-SA 3.0
2013-04-18T21:26:01.870Z
2013-04-18T21:26:01.870Z
Michael Hansen
<p>Readability is often intuitively synthesized. If you see some piece of code, you just <em>know</em> whether it is readable or not. But what are actual <strong>psychological</strong>, scientific explanations for this? </p>

<p>There are readability metrics for written text, but do they apply to source code as well? For example: I believe the word superiority effect to be applicable to source code. What other effects can be found while programming, that make code readable?</p>

<p>I am not looking for educated opinions or examples as in <a href="https://softwareengineering.stackexchange.com/questions/141005/how-would-you-know-if-youve-written-readable-and-easily-maintainable-code">here</a> or <a href="https://softwareengineering.stackexchange.com/questions/162923/what-defines-code-readability">here</a>, but for neural correlates or a perspective from cognitive sciences.</p>

CC BY-SA 3.0
2013-04-09T13:50:23.153Z
There is research for metrics regarding software source code readability, based on readability metrics for natural languages: [Buse and Weimer](http://www.arrestedcomputing.com/pubs/readability-issta.pdf), [Buse and Weimer](http://www.arrestedcomputing.com/pubs/readability-tse.pdf), [Dorn](http://cheetah.cs.virginia.edu/~weimer/students/dorn-mcs-pres.pdf). These don't discuss the psychological roots, however, but may help address your second paragraph about applying readability metrics to source code, how to determine if code is readable, and how to make readable code.
Thomas Owens
CC BY-SA 3.0
2013-04-11T10:36:29.760Z
A related link, on eye-tracking when reading code: http://blog.theincredibleholk.org/blog/2012/12/18/how-do-we-read-code/
Piotr Migdal
<cognitive-psychology><language><reading>
What psychological factors account for code readability?
cessor
# What psychological factors account for code readability?

(Asked by: username_0 on 2013-04-09)

Readability is often intuitively synthesized. If you see some piece of code, you just *know* whether it is readable or not. But what are actual **psychological**, scientific explanations for this?

There are readability metrics for written text, but do they apply to source code as well? For example: I believe the word superiority effect to be applicable to source code. What other effects can be found while programming, that make code readable?

I am not looking for educated opinions or examples as in [here](https://softwareengineering.stackexchange.com/questions/141005/how-would-you-know-if-youve-written-readable-and-easily-maintainable-code) or [here](https://softwareengineering.stackexchange.com/questions/162923/what-defines-code-readability), but for neural correlates or a perspective from cognitive sciences.

**Tags:** cognitive-psychology, language, reading

> **Comments:**
> **username_1**: There is research for metrics regarding software source code readability, based on readability metrics for natural languages: [Buse and Weimer](http://www.arrestedcomputing.com/pubs/readability-issta.pdf), [Buse and Weimer](http://www.arrestedcomputing.com/pubs/readability-tse.pdf), [Dorn](http://cheetah.cs.virginia.edu/~weimer/students/dorn-mcs-pres.pdf). These don't discuss the psychological roots, however, but may help address your second paragraph about applying readability metrics to source code, how to determine if code is readable, and how to make readable code.  
> **username_2**: A related link, on eye-tracking when reading code: http://blog.theincredibleholk.org/blog/2012/12/18/how-do-we-read-code/  

---

## 2 answers

### Answer by username_3 on 2013-04-09. Score: 12

Using the English language, given two sentences that say the same thing, what makes one more readable than the other? Usually terseness while retaining clarity and removing ambiguity.

The exact same things make code more readable. Remove everything that doesn't add anything, but don't remove things that do add information. And avoid ambiguity.

In code, we have the advantage that we can reuse similar pieces of text and replace specific values within them. If only we could do that with books, we could save a small rainforest.

On top of terseness, we have good use of punctuation and spacing. Ever tried to read a blog piece where there are no paragraphs whatsoever? That's what it's like reading code that isn't neatly spaced out.

The psychology of this is simple. Your brain receives all sorts of hints as to what it's reading. Try taking a long piece of text and printing it out (with a serif font) without paragraphs, then without periods and commas, or maybe switch punctuation marks (? => ., ! => :, etc), then in a sans-serif font.

You'll quickly see how much you rely on your brain's instincts when you're reading. Code is exactly the same. And herein lies a problem, because some things are certainly subjective. Or rather they are a matter of habit.

If you're used to seeing underscores preceding member variables, then you move to a company where they don't do that, your brain will still expect the same hints and it will be harder to read. But to change it would mess up everybody else in the team. It would be like moving to Spain and telling them to stop using the preceding [inverse-question mark](http://en.wikipedia.org/wiki/Inverted_question_and_exclamation_marks) because it throws you off.

Design patterns are a similar thing. If everyone knows what a Builder Pattern does, then adding Builder to a class name gives everyone a lot of information. But if I have my own Bracksfort Pattern, that information only helps me, at least until other people start to ask me, or I document it and get the community to buy into it.

> **Comments:**
> **username_3**: @what: Well, yes. If I took a piece of English text and reduced all the nouns and adjectives to one letter, you might struggle to read that too.  
> **username_0**: @what This is what I was going for! I assume that not only the length is important for "readability" but also what the identifier says, so its semantics (Compare the old "#define TRUE FALSE // Happy Debugging" Joke). I found that for example F# Code often reads like maths and is completely unreadable, yet very reasonable. This is mostly due to its abstractness and very concise identifiers.  

---

### Answer by username_4 on 2013-04-18. Score: 7

This is my current area of research (I'm a Ph.D. student in computer science and cognitive science). Like you said, there are a large number of readability/complexity metrics, but very little research trying to quantify what makes a piece of code **psychologically** complex. For more information on *qualitative* studies and models, I'd highly recommend the 2001 book [Software Design: Cognitive Aspects](http://rads.stackoverflow.com/amzn/click/1852332530).

I've been running some experiments recently with the goal of developing a cognitive model that can "read" code like a human. The inspiration for my model largely comes from [a 1995 paper by Simon Cant et. al.](http://www.sciencedirect.com/science/article/pii/095058499591491H). In the paper, they lay down an (incomplete) foundation for a mathematical model that "chunks" small blocks of code into memory and "traces" to other parts of the program in order to resolve dependencies. I have a workshop paper titled "Cognitive architectures: a way forward for the psychology of programming" that suggests we may be able to built such a model on top of a cognitive architecture like ACT-R.

I'm currently writing up the results of one of my experiments. Once it's ready, I'll be posting about it on my blog (synesthesiam.com). In short, we had programmers of all different experience levels predict the output of 10 Python programs (each program had 2 or 3 versions). Some of them did the experiment in front of an eye-tracker, which will be another paper someday (hopefully) soon. The rest were from Mechanical Turk, and we observed interesting speed/accuracy differences that were not always in favor of the more experienced programmers.

> **Comments:**
> **username_6**: Welcome to the site. Thanks for sharing your expertise.  
> **username_0**: Hello user2925, thank you for your answer. I am too planning an experiment right now and I was wondering whether you could share some more of your experiences?  
> **username_4**: Hi @username_0. I'd be happy to share my experiences. What kind of experiment are you planning?  
> **username_0**: @MichaelHansen I think it would be best to discuss this in private! Could you send me an email to the address in my profile? :)  
> **username_4**: **Update**: I posted a paper about the experiment mentioned in my answer [on arXiv](http://arxiv.org/abs/1304.5257).  
> **username_5**: I think this needs a followup that takes into consideration language conventions and the effects of readability from a convention standpoint. Even more interesting would be focusing on C-Syntax languages like Java, C#, and JavaScript which have more syntax intended to delineate blocks which helps with chunking. What happens when you start removing that syntax, or using it in unconventional ways? For instance by chasing "Fewer lines is better".  

---

