reading understanding code n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
reading & understanding code PowerPoint Presentation
Download Presentation
reading & understanding code

Loading in 2 Seconds...

play fullscreen
1 / 92

reading & understanding code - PowerPoint PPT Presentation


  • 82 Views
  • Uploaded on

reading & understanding code. experts are better at code comprehension because they focus on higher level patterns patterns can be considered “discourse rules” naming conventions, design patterns, schemas experts work significantly better when reading & writing code according to these patterns.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'reading & understanding code' - ozzie


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
reading understanding code
reading & understanding code
  • experts are better at code comprehension because they focus on higher level patterns
    • patterns can be considered “discourse rules”
    • naming conventions, design patterns, schemas
  • experts work significantly better when reading & writing code according to these patterns
reading understanding code1

reading & understanding code

program comprehension

expertise effects

mental models

tools

outline
outline
  • mental models
    • types
    • models
  • conventions & “discourse rules”
  • expertise effects
  • tool implications
  • interesting tools
outline1
outline
  • mental models
    • types
    • models
  • conventions & “discourse rules”
  • expertise effects
  • tool implications
  • interesting tools
mental model
mental model
  • explanation of a someone’s thought process when carrying out a task
    • our someone: programmers
    • our task: program comprehension
  • several models exist
mental model classes
mental model classes
  • bottom-up
    • read code statement by statement then ascend for a higher-level picture
  • top-down
    • start with a high-level picture of what the code is doing then descend into code
  • mixed
    • incorporate elements from both, based on the situation
mental model classes1
mental model classes
  • bottom-up
    • read code statement by statement then ascend for a higher-level picture
  • top-down
    • start with a high-level picture of what the code is doing then descend into code
  • mixed
    • incorporate elements from both, based on the situation
bottom up mental models
bottom-up mental models
  • 1st: read code statements
  • 2nd: chunking: group statements as abstractions
  • 3rd: repeat
chunking
chunking

sequence

chunk 1

chunk n

chunk 2

element 1

element k

element 2

modified from wikipedia

chunking1
chunking
  • program model
    • reasoning about the order of computation, how control moves throughout a program
    • “control flow”
  • situation model
    • reason about how data moves through atomic models
    • “data flow”

N. Pennington

Stimulus Structures and Mental Representations in Expert Comprehension of Computer Programs

Cognitive Psychology, 1987

program situation model studies
program & situation model studies
  • participants first primed for either control flow or data flow
    • shown a piece of code, asked to recall another piece of code which is related through either control flow or data flow
  • participants then asked a question that relates to either control or data flow
  • participants primed to think about control flow answered other control-flow questions faster, same with data flow

N. Pennington

Stimulus Structures and Mental Representations in Expert Comprehension of Computer Programs

Cognitive Psychology, 1987

types of programmer knowledge
types of programmer knowledge
  • semantic: general programming concepts
    • low-level knowledge, e.g. what a=1 means
    • high-level knowledge, e.g. sorting algorithms
  • syntactic: language detail
    • overlaps between languages
  • stylistic: programming conventions
    • “discourse rules”

B. Shneiderman and R. Mayer

Syntactic/Semantic Interactions in Programmer Behavior: A Model and Experimental Results

Journal of Computer & Information Sciences, 1979

E. Soloway, K. Ehrlich

Empirical Studies of Programming Knowledge

IEEE Transactions of Software Engineering, 1984

slide13

problem statement

short term memory

internal semantics (working memory)

program

high level concepts

low level concepts

knowledge (long term memory)

semantic knowledge

syntactic knowledge

high level concepts

COBOL

FORTRAN

PL/I

LISP

low level concepts

B. Shneiderman and R. Mayer

Syntactic/Semantic Interactions in Programmer Behavior: A Model and Experimental Results

Journal of Computer & Information Sciences, 1979

evidence for semantic syntactic knowledge
evidence forsemantic & syntactic knowledge
  • lab studies using FORTRAN
    • participants: programmers and non-programmers
    • asked to perform tasks that used one type of knowledge
    • six studies (will describe two)

B. Shneiderman and R. Mayer

Syntactic/Semantic Interactions in Programmer Behavior: A Model and Experimental Results

Journal of Computer & Information Sciences, 1979

program memorization
program memorization
  • study
    • two subject types: non-programmers & programmers
    • two program versions: normal & shuffled
    • participants asked to memorize a program
  • results
    • non-programmers performed equally poorly with normal & shuffled programs
    • programmers performed poorly with shuffled program, well with normal
      • were able to remember semantic details with syntactic variations
  • conclusion
    • programmers were not memorizing the program, but internal semantics to represent its function

B. Shneiderman and R. Mayer

Syntactic/Semantic Interactions in Programmer Behavior: A Model and Experimental Results

Journal of Computer & Information Sciences, 1979

commenting
commenting
  • study
    • two program versions
      • 5-line high-level block comment at top
      • numerous interspersed low-level comments
    • participants asked to make modifications to program & memorize program
  • result
    • high-level comment participants performed better
    • strong correlation between ability to make modifications and ability to memorize
  • conclusion
    • memorization is a strong correlate to comprehension
    • hierarchical chunking to organize statements into a unit facilitate comprehension process

B. Shneiderman and R. Mayer

Syntactic/Semantic Interactions in Programmer Behavior: A Model and Experimental Results

Journal of Computer & Information Sciences, 1979

mental model classes2
mental model classes
  • bottom-up
    • read code statement by statement then ascend for a higher-level picture
  • top-down
    • start with a high-level picture of what the code is doing then descend into code
  • mixed
    • incorporate elements from both, based on the situation
mental model classes3
mental model classes
  • bottom-up
    • read code statement by statement then ascend for a higher-level picture
  • top-down
    • start with a high-level picture of what the code is doing then descend into code
  • mixed
    • incorporate elements from both, based on the situation
top down models
top-down models
  • 1st: develop hypotheses about the program
  • 2nd: evaluate and refine hypotheses
    • with the help of beacons
  • 3rd: repeat
  • a process of “reconstructing knowledge”
beacons
beacons
  • “indexes into existing knowledge”
  • recognizable features in that are cues to the presence of certain structures
  • e.g., looking for a listener pattern

M. Storey

Theories, Methods, and Tools in Program Comprehension: Past, Present, and Future

IEEE Workshop on Program Comprehension, 2005

R. Brooks

Towards a theory of the comprehension of computer programs

International J. on Man-Machine Studies, 1981

beacon types
beacon types
  • semantic knowledge “plans”
    • reusable generic program fragments
    • high-level or low-level
  • programming discourse conventions
    • “rules” that make program comprehension easier
    • found across programmers

E. Soloway, K. Ehrlich

Empirical Studies of Programming Knowledge

IEEE Transactions of Software Engineering, 1984

brooks model
brooks’ model

problem

external representation

requirement documentation

program code

design document

match

beacons

beacons

beacons

syntactic knowledge

semantic knowledge

verify internal schema vs external representation

internal representation –hypotheses and subgoals

R. Brooks

Towards a theory of the comprehension of computer programs

International J. on Man-Machine Studies, 1981

modified from Jonathan I. Maletic’sslides:

An Overview of Mental Models for Program Understanding

mental model classes4
mental model classes
  • bottom-up
    • read code statement by statement then ascend for a higher-level picture
  • top-down
    • start with a high-level picture of what the code is doing then descend into code
  • mixed
    • incorporate elements from both, based on the situation
mental model classes5
mental model classes
  • bottom-up
    • read code statement by statement then ascend for a higher-level picture
  • top-down
    • start with a high-level picture of what the code is doing then descend into code
  • mixed
    • incorporate elements from both, based on the situation
opportunistic systematic strategies
opportunistic & systematic strategies
  • programmers enhancing existing program
  • two strategies:
    • systematically read code in detail, tracing through control and data flow manually
      • developed control and data flow knowledge
    • focus only on code relevant to a task
      • developed only control flow knowledge, resulted in a weaker understanding

Margaret-Anne Storey

Theories, Methods, and Tools in Program Comprehension: Past, Present, and Future

Int. Workshop on Program Comprehension, 2005

integrated model
integrated model
  • maintainers switch between top-down and bottom-up comprehension
    • top-down if code or code type is familiar
    • program model (control-flow) when code is completely unfamiliar
    • situation model (data-flow) after a partial data-flow understanding is developed through top-down or program model methods
    • knowledge base: information from previous three models

Margaret-Anne Storey

Theories, Methods, and Tools in Program Comprehension: Past, Present, and Future

Int. Workshop on Program Comprehension, 2005

A. von Mayrhauser and A.M. Vans

From Program Comprehension to Tool Requirements for an Industrial Environment

IEEE Workshop on Program Comprehension, 1993

validating the integrated model
validating the integrated model
  • taped professional maintenance programmers
    • worked with a large code base
    • classified as domain and language experts
  • tape transcriptions classified into model types
  • one of few studies with real world tasks
outline2
outline
  • mental models
    • types
    • models
  • conventions & “discourse rules”
  • expertise effects
  • tool implications
  • interesting tools
outline3
outline
  • mental models
    • types
    • models
  • conventions & “discourse rules”
  • expertise effects
  • tool implications
  • interesting tools
programming discourse rules
programming discourse rules
  • specify the conventions of programming
    • e.g., a variable’s name should reflect its function
    • e.g., don’t include code that won’t be used
  • similar to writing discourse rules, as outlined in books like Elements of Style
    • e.g., you expect to find the description for fig. 7 between those for fig. 6 and fig. 8

E. Soloway, K. Ehrlich

Empirical Studies of Programming Knowledge

IEEE Transactions of Software Engineering, 1984

rules of programming discourse
rules of programming discourse
  • variable names should reflect function
  • don’t include code that won’t be used
    • if there is a test for a condition, then the condition must have the potential of being true
  • a variable that is initialized via an assignment statement should be updated via an assignment statement
  • don’t do double duty with code in a non-obvious way
  • an if should be used when a statement body is guaranteed to be executed only once, and a while used when a statement body may need to be repeatedly executed

E. Soloway, K. Ehrlich

Empirical Studies of Programming Knowledge

IEEE Transactions of Software Engineering, 1984

testing discourse rules
testing discourse rules
  • lab study with expert & novice programmers
  • two program types
    • α (plan-like): obeyed discourse rules
    • β (un-plan-like): disobeyed discourse rules
  • participants given either α or β code, with one blank
  • task:fill the blank with what seems “natural”
    • participants were not told about α or β code
  • conclusion: experts fared best with α code
why have un plan like code
why have un-plan-like (β) code?
  • machine limitations
    • limited memory, processing, bandwidth, etc.
  • language limitations
    • less common. bugs, efficiency issues, etc.
  • programmer limitations
    • does not have full mastery of discourse
  • historical traces
    • resistance to changing legacy code, permanent “temporary” code

source:

The Psychology of

Computer Programming

slide35

XXX: PROCEDURE OPTIONS(MAIN);

DECLARE B(1000) FIXED(7,2),

C FIXED(11,2),

(I, J) FIXED BINARY;

C = 0;

DO I = 1 TO 10;

GET LIST((B(J) DO J = 1 TO 1000));

DO J = 1 TO 1000;

C = C + B(J);

END;

END;

PUT LIST(‘RESULT IS ’, C);

END XXX;

modified from The Psychology of

Computer Programming

slide36

XXX: PROCEDURE OPTIONS(MAIN);

DECLARE A(1000) FIXED(7,2),

C FIXED(11,2),

I FIXED BINARY;

C = 0;

GET LIST((A(J) DO I = 1 TO 10000));

DO I = 1 TO 10000;

C = C + B(I);

END;

PUT LIST(‘RESULT IS ’, C);

END XXX;

modified from

The Psychology of

Computer Programming

rules of programming discourse1
rules of programming discourse
  • variable names should reflect function
  • don’t include code that won’t be used
    • if there is a test for a condition, then the condition must have the potential of being true
  • a variable that is initialized via an assignment statement should be updated via an assignment statement
  • don’t do double duty with code in a non-obvious way
  • an if should be used when a statement body is guaranteed to be executed only once, and a while used when a statement body may need to be repeatedly executed

E. Soloway, K. Ehrlich

Empirical Studies of Programming Knowledge

IEEE Transactions of Software Engineering, 1984

rules of programming discourse2
rules of programming discourse
  • variable names should reflect function
  • don’t include code that won’t be used
    • if there is a test for a condition, then the condition must have the potential of being true
  • a variable that is initialized via an assignment statement should be updated via an assignment statement
  • don’t do double duty with code in a non-obvious way
  • an if should be used when a statement body is guaranteed to be executed only once, and a while used when a statement body may need to be repeatedly executed

E. Soloway, K. Ehrlich

Empirical Studies of Programming Knowledge

IEEE Transactions of Software Engineering, 1984

naming conventions
naming conventions
  • meaningful names
    • variable naming reflects cognitive structure
  • grammatical sensibility
    • interact with language spec. to form expressions
  • containers & paths
    • objects & pointers
  • polysemy, homonymy, & overloading
    • operators, name sharing

B. Liblit, A. Begel, and E. Sweetser

Cognitive Perspectives on the Role of Naming in Computer Programs

Psychology of Programming Interest Group, 2006

naming conventions1
naming conventions
  • meaningful names
    • variable naming reflects cognitive structure
  • grammatical sensibility
    • interact with language spec. to form expressions
  • containers & paths
    • objects & pointers
  • polysemy, homonymy, & overloading
    • operators, name sharing

B. Liblit, A. Begel, and E. Sweetser

Cognitive Perspectives on the Role of Naming in Computer Programs

Psychology of Programming Interest Group, 2006

meaningful names
meaningful names
  • metaphors for domain tasks
    • e.g. pushing objects onto a stack
  • keywords for grouping
    • e.g. common prefixes & suffixes
  • informative names
    • balanced with name length

A. Blackwell

Metaphor or analogy: how should we see programming abstractions?

Psychology of Programming Interest Group, 1996

B. Liblit, A. Begel, and E. Sweetser

Cognitive Perspectives on the Role of Naming in

Computer Programs

Psychology of Programming Interest Group, 2006

name length
name length
  • length harm readability and recall ability
  • idioms and memory ties improve readability and recall ability
  • takeaway: variable names with consistent and abbreviated vocabulary are optimal
    • (variable names that concisely express a metaphor)

D. Binkley, D. Lawrie, S. Maex, and C. Morrell

Identifier length and limited programmer memory

Science of Computer Programming, 2009

grammatical sensibility
grammatical sensibility
  • names as phrase fragments
    • methods as actions (change state of program)
      • e.g. addElement, setSize, removeAll
    • methods as mathematical functions (compute result, don’t alter state)
      • e.g. true/false: contains, equals, isEmpty
      • e.g. data: capacity, indexOf, size
  • valence cues (phrase fragments w/ open slot)
    • e.g. roster.contains(player)
    • smalltalk makes use of this extensively:
      • roster insert: player at: position

B. Liblit, A. Begel, and E. Sweetser

Cognitive Perspectives on the Role of Naming in Computer Programs

Psychology of Programming Interest Group, 2006

outline4
outline
  • mental models
    • types
    • models
  • conventions & “discourse rules”
  • expertise effects
  • tool implications
  • interesting tools
outline5
outline
  • mental models
    • types
    • models
  • conventions & “discourse rules”
  • expertise effects
  • tool implications
  • interesting tools
20 1 programmer performance
20:1 programmer performance
  • Sackman et al.: best programmers are 20xbetter than worst programmers @ bug fixing
    • study originally meant to evaluate the effectiveness of time-shared systems

H. Sackman, W. J. Erikson, and E. E. Grant

Exploratory experimental studies comparing online and offline programming performance

Communications of the ACM, 1968

10 1 programmer performance
10:1 programmer performance
  • there are substantial programmer efficiency differences, but not as dramatic as initially reported
  • what makes experts so much better at understanding code?
testing discourse rules1
testing discourse rules
  • lab study with expert & novice programmers
  • two program types
    • α (plan-like): obeyed discourse rules
    • β (un-plan-like): disobeyed discourse rules
  • participants given either α or β code, with one blank
  • task:fill the blank with what seems “natural”
    • participants were not told about α or β code
problem
α problem

PROGRAM Magenta(input, output)

VAR Max, I, Num INTEGER

BEGIN

Max = 0.

FOR I = 1 TO 10 DO

BEGIN

READLN(Num)

If Num Max THEN Max = Num

END

WRITELN(Max).

END

?

E. Soloway, K. Ehrlich

Empirical Studies of Programming Knowledge

IEEE Transactions of Software Engineering, 1984

solution
α solution

PROGRAM Magenta(input, output)

VAR Max, I, Num INTEGER

BEGIN

Max = 0.

FOR I = 1 TO 10 DO

BEGIN

READLN(Num)

If Num > Max THEN Max = Num

END

WRITELN(Max).

END

E. Soloway, K. Ehrlich

Empirical Studies of Programming Knowledge

IEEE Transactions of Software Engineering, 1984

problem1
β problem

PROGRAM Magenta(input, output)

VAR Max, I, Num INTEGER

BEGIN

Max = 999999.

FOR I = 1 TO 10 DO

BEGIN

READLN(Num)

If Num Max THEN Max = Num

END

WRITELN(Max).

END

?

E. Soloway, K. Ehrlich

Empirical Studies of Programming Knowledge

IEEE Transactions of Software Engineering, 1984

solution1
β solution

PROGRAM Magenta(input, output)

VAR Max, I, Num INTEGER

BEGIN

Max = 999999.

FOR I = 1 TO 10 DO

BEGIN

READLN(Num)

If Num < Max THEN Max = Num

END

WRITELN(Max).

END

E. Soloway, K. Ehrlich

Empirical Studies of Programming Knowledge

IEEE Transactions of Software Engineering, 1984

percentage of correct responses
percentage of correct responses

E. Soloway, K. Ehrlich

Empirical Studies of Programming Knowledge

IEEE Transactions of Software Engineering, 1984

debugging differences between novices and experts
debugging differences between novices and experts
  • experts: situation-dependent problem solvers
  • novices: situation-independent problem solvers

I. Vessey

Expertise in Debugging Computer Programs: An analysis of the Content of Verbal Protocols

IEEE Trans on Systems, Man, Cybernetics, 1986

outline6
outline
  • mental models
    • types
    • models
  • conventions & “discourse rules”
  • expertise effects
  • tool implications
  • interesting tools
outline7
outline
  • mental models
    • types
    • models
  • conventions & “discourse rules”
  • expertise effects
  • tool implications
  • interesting tools
tool implications
tool implications
  • browsing support
    • browse from high to low level and low to high level
  • searching
    • looking for snippets by analogy
  • multiple views
    • show orthogonal object relationships
  • context-driven views
    • determine best view based on context
  • additional cognitive support
    • external devices to support cognitive tasks needed

Margaret-Anne Storey

Theories, Methods, and Tools in Program Comprehension: Past, Present, and Future

Int. Workshop on Program Comprehension, 2005

tool implications1
tool implications
  • browsing support
    • browse from high to low level and low to high level
  • searching
    • looking for snippets by analogy
  • multiple views
    • show orthogonal object relationships
  • context-driven views
    • determine best view based on context
  • additional cognitive support
    • external devices to support cognitive tasks needed

Margaret-Anne Storey

Theories, Methods, and Tools in Program Comprehension: Past, Present, and Future

Int. Workshop on Program Comprehension, 2005

browsing support
browsing support
  • traverse control and data flow paths
  • switching between top-down and bottom-up models
  • breadth-first and depth-first
tool implications2
tool implications
  • browsing support
    • browse from high to low level and low to high level
  • searching
    • looking for snippets by analogy
  • multiple views
    • show orthogonal object relationships
  • context-driven views
    • determine best view based on context
  • additional cognitive support
    • external devices to support cognitive tasks needed

Margaret-Anne Storey

Theories, Methods, and Tools in Program Comprehension: Past, Present, and Future

Int. Workshop on Program Comprehension, 2005

tool implications3
tool implications
  • browsing support
    • browse from high to low level and low to high level
  • searching
    • looking for snippets by analogy
  • multiple views
    • show orthogonal object relationships
  • context-driven views
    • determine best view based on context
  • additional cognitive support
    • external devices to support cognitive tasks needed

Margaret-Anne Storey

Theories, Methods, and Tools in Program Comprehension: Past, Present, and Future

Int. Workshop on Program Comprehension, 2005

searching
searching
  • search for code snippets
    • not just by text
  • example: query the role of a variable, when a function is called
  • useful for top-down hypothesis testing
tool implications4
tool implications
  • browsing support
    • browse from high to low level and low to high level
  • searching
    • looking for snippets by analogy
  • multiple views
    • show orthogonal object relationships
  • context-driven views
    • determine best view based on context
  • additional cognitive support
    • external devices to support cognitive tasks needed

Margaret-Anne Storey

Theories, Methods, and Tools in Program Comprehension: Past, Present, and Future

Int. Workshop on Program Comprehension, 2005

tool implications5
tool implications
  • browsing support
    • browse from high to low level and low to high level
  • searching
    • looking for snippets by analogy
  • multiple views
    • show orthogonal object relationships
  • context-driven views
    • determine best view based on context
  • additional cognitive support
    • external devices to support cognitive tasks needed

Margaret-Anne Storey

Theories, Methods, and Tools in Program Comprehension: Past, Present, and Future

Int. Workshop on Program Comprehension, 2005

multiple views
multiple views
  • multiple ways of viewing programs
    • call graph
    • object hierarchy
    • etc.
  • different views are applicable for different tasks
tool implications6
tool implications
  • browsing support
    • browse from high to low level and low to high level
  • searching
    • looking for snippets by analogy
  • multiple views
    • show orthogonal object relationships
  • context-driven views
    • determine best view based on context
  • additional cognitive support
    • external devices to support cognitive tasks needed

Margaret-Anne Storey

Theories, Methods, and Tools in Program Comprehension: Past, Present, and Future

Int. Workshop on Program Comprehension, 2005

tool implications7
tool implications
  • browsing support
    • browse from high to low level and low to high level
  • searching
    • looking for snippets by analogy
  • multiple views
    • show orthogonal object relationships
  • context-driven views
    • determine best view based on context
  • additional cognitive support
    • external devices to support cognitive tasks needed

Margaret-Anne Storey

Theories, Methods, and Tools in Program Comprehension: Past, Present, and Future

Int. Workshop on Program Comprehension, 2005

context driven views
context-driven views
  • alter views based on program metrics
    • size of program
    • interdependence of modules
    • flatness of hierarchy
    • etc.
tool implications8
tool implications
  • browsing support
    • browse from high to low level and low to high level
  • searching
    • looking for snippets by analogy
  • multiple views
    • show orthogonal object relationships
  • context-driven views
    • determine best view based on context
  • additional cognitive support
    • external devices to support cognitive tasks needed

Margaret-Anne Storey

Theories, Methods, and Tools in Program Comprehension: Past, Present, and Future

Int. Workshop on Program Comprehension, 2005

tool implications9
tool implications
  • browsing support
    • browse from high to low level and low to high level
  • searching
    • looking for snippets by analogy
  • multiple views
    • show orthogonal object relationships
  • context-driven views
    • determine best view based on context
  • additional cognitive support
    • external devices to support cognitive tasks needed

Margaret-Anne Storey

Theories, Methods, and Tools in Program Comprehension: Past, Present, and Future

Int. Workshop on Program Comprehension, 2005

additional cognitive support
additional cognitive support
  • experts:
    • tools to support cognitive tasks
      • external devices
      • scratchpads
  • novices
    • pedagogical support
      • programming language
      • task domain
outline8
outline
  • mental models
    • types
    • models
  • conventions & “discourse rules”
  • expertise effects
  • tool implications
  • interesting tools
outline9
outline
  • mental models
    • types
    • models
  • conventions & “discourse rules”
  • expertise effects
  • tool implications
  • interesting tools
structured editors
structured editors
  • reduce burden or memorizing syntax
    • focus on semantics

A. Ko and B. Myers

Citrus: A Language and Toolkit for Simplifying the Creation of Structured Editors for Code and Data

UIST, 2005

literate programming
literate programming
  • source code interwoven with exposition of logic, like an essay
  • allows programmers to work top-down or bottom-up

D. Knuth

Literate Programming

Journal of Computer & Information Sciences, 1979

slide78

The purpose of wc is to count lines, words, and/or characters in a list of files. The

number of lines in a file is ......../more explanations/

Here, then, is an overview of the file wc.c that is defined by the noweb program wc.nw:

<<*>>=

<<Header files to include>>

<<Definitions>>

<<Global variables>>

<<Functions>>

<<The main program>>

@

We must include the standard I/O definitions, since we want to send formatted output

to stdout and stderr.

<<Header files to include>>=

#include <stdio.h>

@

D. Knuth

Literate Programming

Journal of Computer & Information Sciences, 1979

c onclusion
conclusion
  • beginners start off with an incomplete mental model for how code works
  • experts are better at code comprehension because they focus on higher level patterns
    • patterns can be considered “discourse rules”
    • naming conventions, design patterns, schemas
  • experts work significantly better when reading & writing code according to these patterns
discussion
discussion
  • what other discourse rules can you think of?
  • do these mental models resonate with your style of understanding code?
  • what are some other tool implications of these models?
references 1
references - 1

B. Shneidermanand R. Mayer

Syntactic/Semantic Interactions in Programmer Behavior: A Model and Experimental Results

Journal of Computer & Information Sciences, 1979

R. Brooks

Towards a theory of the comprehension of computer programs

International J. on Man-Machine Studies, 1981

N. Pennington

Stimulus Structures and Mental Representations in Expert Comprehension of Computer Programs

Cognitive Psychology, 1987

D. Knuth

Literate Programming

Journal of Computer & Information Sciences, 1979

H. Sackman, W. J. Erikson, and E. E. Grant

Exploratory experimental studies comparing online and offline programming performance

Communications of the ACM, 1968

B. Liblit, A. Begel, and E. Sweetser

Cognitive Perspectives on the Role of Naming in Computer Programs

Psychology of Programming Interest Group, 2006

A. Blackwell

Metaphor or analogy: how should we see programming abstractions?

Psychology of Programming Interest Group, 1996

E. Soloway, K. Ehrlich

Empirical Studies of Programming Knowledge

IEEE Transactions of Software Engineering, 1984

references 2
references - 2

I. Vessey

Expertise in Debugging Computer Programs: An analysis of the Content of Verbal Protocols

IEEE Trans on Systems, Man, Cybernetics, 1986

A. Ko and B. Myers

Citrus: A Language and Toolkit for Simplifying the Creation of Structured Editors for Code and Data

UIST, 2005

A. von Mayrhauser and A.M. Vans

From Program Comprehension to Tool Requirements for an Industrial Environment

IEEE Workshop on Program Comprehension, 1993

Margaret-Anne Storey

Theories, Methods, and Tools in Program Comprehension: Past, Present, and Future

Int. Workshop on Program Comprehension, 2005

does visual programming help
does visual programming help?

C. Hundhausen, S. Douglas, J. Stasko

A meta-study of algorithm

visualization effectiveness

Journal of Visual Languages & Computing, 2002

underlying questions
underlying questions
  • how do programmers read and come to understand unfamiliar code?
  • what kinds of mental models to programmers create to think about code?
  • why are experts significantly better than novices when looking at unfamiliar code?
    • hint: experts aren’t as good as you might expect!
why does it matter
why does it matter?
  • reading code is done when:
    • searching for relevant code
    • re-acquainting oneself with a project
    • reading someone else’s code
    • refactoring
the gist of the talk
the gist of the talk
  • beginners start off with an incomplete mental model for how code works
  • experts are better at code comprehension because they focus on higher level patterns
    • patterns can be considered “discourse rules”
    • naming conventions, design patterns, schemas
  • experts work significantly better when reading & writing code according to these patterns
slide87

varDict=function() {

this.keys = [];

this.values = [];

};

Dict.prototype.set = function(key, value) {

varkeyIndex=this.keys.indexOf(key);

if(keyIndex<0) {

this.keys.push(key);

this.values.push(value);

}

else {

this.values[keyIndex] = value;

}

};

Dict.prototype.get = function(key) {

var keyIndex = this.keys.indexOf(key);

if(keyIndex>=0) returnthis.values[keyIndex];

returnundefined;

};

mental models
mental models

top-down models

bottom-up models

1st: read code statements

2nd: mental chunking

start on a low level, ascend

  • 1st: hypothesize about code
  • 2nd: check hypotheses
  • start on a high level, dig in

hybrid models

  • incorporate elements from both, based on the situation
shneiderman mayer s model
shneiderman & mayer’s model
  • semantic knowledge: general programming concepts
    • low-level knowledge, e.g. what assignments do
    • high-level knowledge, e.g. algorithms
  • syntactic knowledge: programming language details
    • sometimes overlaps across programming langs.

B. Shneiderman and R. Mayer

Syntactic/Semantic Interactions in Programmer Behavior: A Model and Experimental Results

Journal of Computer & Information Sciences, 1979

brooks model1
brooks’ model
  • “top-down”
    • analyze code on a high level, then look at specifics
  • argues that programmers form a series of hypotheses
  • beacons help verify or reject these hypotheses

R. Brooks

Towards a theory of the comprehension of computer programs

International J. on Man-Machine Studies, 1981

containers paths
containers & paths

B. Liblit, A. Begel, and E. Sweetser

Cognitive Perspectives on the Role of Naming in Computer Programs

Psychology of Programming Interest Group, 2006

polysemy homonymy overloading
polysemy, homonymy, & overloading

B. Liblit, A. Begel, and E. Sweetser

Cognitive Perspectives on the Role of Naming in Computer Programs

Psychology of Programming Interest Group, 2006