What psychological factors account for code readability? 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 or here, but for neural correlates or a perspective from cognitive sciences.
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 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.