What Makes Code Readable: Not What You Think

April 19, 2013 at 1:58 am 8 comments

This is a nice post considering the interaction between language complexity, readability, and learnability.  It could have been made stronger by including some of the empirical data.  Thomas Green in his empirical research on language features didn’t just find that explicit BEGIN IF…END IF blocks were easier to read by novices, he found that they were TEN TIMES easier for novices to read.  Being less succinct is not just easier for novices, it may be so much easier that it’s the difference between success and giving up.

My point is, the larger the vocabulary you have, the more succinctly ideas can be expressed, thus making them more readable, BUT only to those who have a mastery of that vocabulary and grammar.

If we made the English language smaller, and reduced the complex rules of grammar to a more much simple structure, we’d make it much easier to learn, but we’d make it harder to convey information.

via What Makes Code Readable: Not What You Think | Making the Complex Simple.

Entry filed under: Uncategorized. Tags: , .

Computer Science as a great target for Science Careers CSTA 2013 Conference Registration now open

8 Comments Add your own

  • 1. Rebecca Dovi  |  April 19, 2013 at 10:43 am

    This is part of what I miss @ QBasic

    There was a paper presented at SIGCSE last year that was somewhat related. She looked at other languages people used to communicate directions – specifically knitting patterns, for the same kinds of information.

    In knitting you give the direction – knit one, purl three – THEN you tell how many times you repeat that instruction. She found that was much easier for novices to understand.

  • 2. drj11  |  April 19, 2013 at 10:52 am

    I couldn’t really see how the wikipedia page you linked to (!) supported your case that “explicit BEGIN IF…END IF blocks were easier to read by novices”.

    Can you expand please?

    • 3. Mark Guzdial  |  April 19, 2013 at 11:09 am

      I was pointing to that page as a nice summary of T.R.G. Green’s work. Here is a quote from his chapter “Programming as a Cognitive Activity” which references the finding I’m referencing above.

  • […] What Makes Code Readable: Not What You Think | Computing Education Blog. […]

  • 5. guy  |  April 19, 2013 at 8:20 pm

    Like you, I’d like to see the author go into more detail. I agree with John Sonmez, but it is only my opinion based upon my experience attempting to teach introductory programming. I initially attempted to use Java as an introductory language. Brian Harvey moved me to the use of Logo and it just is so much easier to learn in little steps, a very limited concept at a time.

    The HelloWorld program is simply

    print [ Hello World! ]

    Think about simple iteration. In introductory Logo, it is common to see a box drawn with the command:

    repeat 4 [ forward 100 right 90 ]

    How do you write this in Java given a TurtleGraphics class with methods like forward() and right()?

    for ( int i=1; i <= 4; i++ )
    turtle.forward( 100 );
    turtle.right( 90 );

    To understand the "for" statement, the student needs to understand variable declarations, assignment operations, boolean expressions, increment operations, block structure, class method invocations, in addition to a plethora of punctuation. And then, put it all together to finally understand the for statement itself – what it's doing.

    In addition to a language's vocabulary, I've found that type-less variables also postpone another area of complexity. Typed data is very important; but, not in an introduction to programming class (IMO).

    Students can be introduced to programming in Logo in microsteps. That's my experience. I'd love to see the author's theory confirmed or disproved in some form of cognitive experiment/analysis…

    • 6. chaikens  |  April 22, 2013 at 7:13 am

      The need for a variable to code loop that repeats a fixed sequence (like forward(100); right(90)) certainly makes such a loop harder for beginners. However, the conception and programming of dynamic changing and testing of variable values needs to be taught eventually, and is likely (evidenced by Sorva’s work) to be much more difficult. There is the risk that the [block of things] repeat n; syntax will make it harder for us to motivate the complex of setting up, initializing, testing and updating variable and their values.

  • […] as set operations, favoring replicated code over abstraction in the first half of the semester, avoiding else.  They thought that those were interesting ideas to consider adding to the course.  I borrowed a […]

  • […] example, David replicated the result that else clauses in text are really hard for novices (which I talked about here), but students perform much better in […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Trackback this post  |  Subscribe to the comments via RSS Feed

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 9,052 other followers


Recent Posts

Blog Stats

  • 2,030,410 hits
April 2013

CS Teaching Tips

%d bloggers like this: