"Code is read more than it is written"

Question

I often hear the adage, "Code is read more than it is written." I happen to agree with this sentiment, but I can't find any studies or statistics to back it up. Has anyone come across a substantial finding on this topic (something more than an apocryphal tale) or, better yet, done this sort of research?

Answer 1

You could check out this post from The Old New Thing blog:

Code is read much more often than it is written, so plan accordingly:

http://blogs.msdn.com/b/oldnewthing/archive/2007/04/06/2036150.aspx

[...]

Even if you don't intend anybody else to read your code, there's still a very good chance that somebody will have to stare at your code and figure out what it does: That person is probably going to be you, twelve months from now.

[...]

Your code is really the design of your application, so it helps when performing handovers and code reviews to make that design as simple as possible for the reader to understand. Some developers are actively against writing comments in their code, some believe that if you are writing a comment, you are having to explain a design decision which the reader should be able to understand from the structure of a well designed system, without comments.

http://lingpipe-blog.com/2009/10/15/the-futility-of-commenting-code/

Answer 2

I don't know of any academic writing supporting this, but it is obvious that the coder needs to constantly reread their code as they write the rest of it and as it evolves. Later, debugging and testing require a lot of reading and often insubstantial amounts of written change. And even later, other people might try to reuse it, before which they must know how it works.

Answer 3

Even I googled it and found out the reason behind it in MSDN's Blog... The very first line said

Even if you don't intend anybody else to read your code, there's still a very good chance that somebody will have to stare at your code and figure out what it does: That person is probably going to be you, twelve months from now.

The best practice is to write it in a manner that the next person working on that project can understand your code easily.It's better to add naming conventions in manner that even a 10th standard boy can easily understand it.There are some situations when you deliver a application and then after some months Client come back for some further modifications.And sometimes it becomes very difficult to recall all the stuff you have written some months back.That's why this thing is said.You write your code once,but you have to read it over and over,and even if that project is passed on to another team,then too it must easily readable.

Answer 4

Based on your comment to scott77777's answer:

Yes, I find it obvious, but I'm having a struggle with certain people at work who are convinced that (1) once they write something, nobody will else will ever need to read it, and (2) "if it works, it works" i.e. there is no value in writing understandable code, so long as it functions properly. Hence my wanting to find hard data to back up my claims to the contrary.

Then what those people you're arguing against need to do is to find examples of code bases that have zero bugs/defects. Only those code bases will have been (possibly) write-only. Otherwise, every reported bug or defect is going to have resulted in someone (either the original developer, or someone else) having to re-read some of the code.

I'm willing to bet that only the most trivial of codebases have zero bugs/defects - and even then, it's probably because the code isn't used rather than it being perfect - I've seen defects in "hello world" examples that people have written out quickly without actually throwing a compiler at them.