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 amp writing code according to these patterns ID: 380462
Download Presentation The PPT/PDF document "reading & understanding code" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
reading & understanding code
experts are better at code comprehension because they focus on higher level patternspatterns can be considered “discourse rules”naming conventions, design patterns, schemasexperts work significantly better when reading & writing code according to these patterns
1Slide2
reading & understanding code
program comprehensionexpertise effectsmental modelstools
2Slide3
outline
mental modelstypesmodelsconventions & “discourse rules”expertise effectstool implicationsinteresting tools
3Slide4
outline
mental modelstypesmodelsconventions & “discourse rules”expertise effects
tool implications
interesting tools
4Slide5
mental model
explanation of a someone’s thought process when carrying out a taskour someone: programmersour task: program comprehension
several models exist
5Slide6
mental model classes
bottom-upread code statement by statement then ascend for a higher-level picturetop-downstart with a high-level picture of what the code is doing
then
descend into code
mixed
incorporate elements from both, based on the situation
6Slide7
mental model classes
bottom-upread code statement by statement then ascend for a higher-level picturetop-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
7Slide8
bottom-up mental models
1st: read code statements2nd: chunking
: group statements as abstractions
3
rd
: repeat
8Slide9
chunking
9
sequence
chunk 1
chunk 2
chunk n
element 1
element
2
element k
modified from
wikipediaSlide10
chunking
program modelreasoning 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
”
10
N. Pennington
Stimulus Structures and Mental Representations in Expert Comprehension of Computer Programs
Cognitive Psychology, 1987Slide11
program & situation model studies
participants first primed for either control flow or data flowshown a piece of code, asked to recall another piece of code which is related through either control flow or data flowparticipants 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
11
N. Pennington
Stimulus Structures and Mental Representations in Expert Comprehension of Computer Programs
Cognitive Psychology, 1987Slide12
types of programmer knowledge
semantic: general programming conceptslow-level knowledge, e.g. what a=1 meanshigh-level knowledge, e.g. sorting algorithms
syntactic
: language detail
overlaps between languages
stylistic
: programming conventions
“discourse rules”
12
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, 1984Slide13
13
problem statement
program
short term memory
internal semantics (working memory)
knowledge (long term memory)
syntactic knowledge
COBOL
FORTRAN
PL/I
LISP
semantic knowledge
high level concepts
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
high level concepts
low level conceptsSlide14
evidence for
semantic & syntactic knowledgelab studies using FORTRANparticipants: programmers and non-programmersasked to perform tasks that used one type of knowledge
six studies (will describe two)
14
B.
Shneiderman
and R. Mayer
Syntactic/Semantic Interactions in Programmer Behavior: A Model and Experimental
Results
Journal of Computer & Information Sciences, 1979Slide15
program memorization
studytwo 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, 1979Slide16
commenting
studytwo program versions5-line high-level block comment at topnumerous 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
16
B.
Shneiderman
and R. Mayer
Syntactic/Semantic Interactions in Programmer Behavior: A Model and Experimental
Results
Journal of Computer & Information Sciences, 1979Slide17
mental model classes
bottom-upread code statement by statement then ascend for a higher-level picturetop-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
17Slide18
mental model classes
bottom-upread 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
18Slide19
top-down models
1st: develop hypotheses about the program2nd: evaluate and refine hypotheses
with the help of
beacons
3
rd
: repeat
a process of “
reconstructing knowledge
”
19Slide20
beacons
“indexes into existing knowledge”recognizable features in that are cues to the presence of certain structurese.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, 1981Slide21
beacon types
semantic knowledge “plans”reusable generic program fragmentshigh-level or low-levelprogramming discourse conventions“rules” that make program comprehension easier
found across programmers
21
E.
Soloway
, K. Ehrlich
Empirical Studies of Programming Knowledge
IEEE Transactions of Software Engineering, 1984Slide22
brooks’ model
22
R. Brooks
Towards a theory of the comprehension of computer programs
International J. on Man-Machine Studies, 1981
modified from
Jonathan
I.
Maletic’s
slides:
An Overview of Mental Models for
Program
Understanding
requirement documentation
internal representation
–hypotheses
and
subgoals
design document
program code
verify internal schema
vs
external representation
external representation
beacons
beacons
beacons
syntactic knowledge
problem
semantic knowledge
matchSlide23
mental model classes
bottom-upread 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
23Slide24
mental model classes
bottom-upread 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
24Slide25
opportunistic & systematic strategies
programmers enhancing existing programtwo strategies:systematically read code in detail, tracing through control and data flow manuallydeveloped control and data flow knowledge
focus only on code relevant to a task
developed only control flow knowledge, resulted in a weaker understanding
25
Margaret-Anne
Storey
Theories, Methods, and Tools in Program Comprehension: Past, Present, and Future
Int. Workshop on Program Comprehension, 2005Slide26
integrated model
maintainers switch between top-down and bottom-up comprehensiontop-down if code or code type is familiarprogram model (control-flow) when code is completely unfamiliarsituation 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
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, 2005Slide27Slide28
validating the integrated model
taped professional maintenance programmersworked with a large code baseclassified as domain and language expertstape transcriptions classified into model typesone of few studies with real world tasks
28Slide29
outline
mental modelstypesmodelsconventions & “discourse rules”expertise effects
tool implications
interesting tools
29Slide30
outline
mental modelstypesmodelsconventions & “discourse rules”
expertise effects
tool implications
interesting tools
30Slide31
programming discourse rules
specify the conventions of programminge.g., a variable’s name should reflect its functione.g., don’t include code that won’t be usedsimilar 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
31
E.
Soloway
, K. Ehrlich
Empirical Studies of Programming Knowledge
IEEE Transactions of Software Engineering, 1984Slide32
rules of programming discourse
variable names should reflect functiondon’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
32
E.
Soloway
, K. Ehrlich
Empirical Studies of Programming Knowledge
IEEE Transactions of Software Engineering, 1984Slide33
testing discourse rules
lab study with expert & novice programmerstwo 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
33Slide34
why have un-plan-like (β) code?
machine limitationslimited memory, processing, bandwidth, etc.language limitationsless common. bugs, efficiency issues, etc.programmer limitations
does not have full mastery of discourse
historical traces
resistance to changing legacy code, permanent “temporary” code
34
source:
The Psychology of
Computer ProgrammingSlide35
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;
35
modified from
The Psychology of
Computer ProgrammingSlide36
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;
36
modified from
The Psychology of
Computer ProgrammingSlide37
rules of programming discourse
variable names should reflect functiondon’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
37
E.
Soloway
, K. Ehrlich
Empirical Studies of Programming Knowledge
IEEE Transactions of Software Engineering, 1984Slide38
rules of programming discourse
variable names should reflect functiondon’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
38
E.
Soloway
, K. Ehrlich
Empirical Studies of Programming Knowledge
IEEE Transactions of Software Engineering, 1984Slide39
naming conventions
meaningful namesvariable naming reflects cognitive structuregrammatical sensibilityinteract with language spec. to form expressionscontainers & paths
objects & pointers
polysemy, homonymy, & overloading
operators, name sharing
39
B.
Liblit
, A.
Begel
, and E.
Sweetser
Cognitive Perspectives on the Role of Naming in Computer Programs
Psychology of Programming Interest Group, 2006Slide40
naming conventions
meaningful namesvariable naming reflects cognitive structuregrammatical sensibilityinteract with language spec. to form expressionscontainers & paths
objects & pointers
polysemy, homonymy, & overloading
operators, name sharing
40
B.
Liblit
, A.
Begel
, and E.
Sweetser
Cognitive Perspectives on the Role of Naming in Computer Programs
Psychology of Programming Interest Group, 2006Slide41
meaningful names
metaphors for domain taskse.g. pushing objects onto a stackkeywords for groupinge.g. common prefixes & suffixesinformative names
balanced with name
length
41
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, 2006Slide42
name length
length harm readability and recall abilityidioms and memory ties improve readability and recall abilitytakeaway: variable names with consistent and abbreviated vocabulary are optimal
(variable names that concisely express a metaphor)
42
D. Binkley, D.
Lawrie
, S.
Maex
, and C. Morrell
Identifier length and limited programmer memory
Science of Computer Programming, 2009Slide43
grammatical sensibility
names as phrase fragmentsmethods 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
43
B.
Liblit
, A.
Begel
, and E. Sweetser
Cognitive Perspectives on the Role of Naming in Computer ProgramsPsychology of Programming Interest Group, 2006Slide44
outline
mental modelstypesmodelsconventions & “discourse rules”
expertise effects
tool implications
interesting tools
44Slide45
outline
mental modelstypesmodelsconventions & “discourse rules”
expertise effects
tool implications
interesting tools
45Slide46
20:1 programmer performance
Sackman et al.: best programmers are 20x better 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
46Slide47
10:1 programmer performance
there are substantial programmer efficiency differences, but not as dramatic as initially reportedwhat makes experts so much better at understanding code?
47Slide48
testing discourse rules
lab study with expert & novice programmerstwo 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
48Slide49
α 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
?
49
E.
Soloway
, K. Ehrlich
Empirical Studies of Programming Knowledge
IEEE Transactions of Software Engineering, 1984Slide50
α 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
50
E.
Soloway
, K. Ehrlich
Empirical Studies of Programming Knowledge
IEEE Transactions of Software Engineering, 1984Slide51
β 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
?
51
E.
Soloway
, K. Ehrlich
Empirical Studies of Programming Knowledge
IEEE Transactions of Software Engineering, 1984Slide52
β 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
52
E.
Soloway
, K. Ehrlich
Empirical Studies of Programming Knowledge
IEEE Transactions of Software Engineering, 1984Slide53
percentage of correct responses
53
E.
Soloway
, K. Ehrlich
Empirical Studies of Programming Knowledge
IEEE Transactions of Software Engineering, 1984Slide54
debugging differences between novices and experts
experts:
situation-dependent problem solvers
novices:
situation-independent
problem solvers
54
I.
Vessey
Expertise in Debugging Computer Programs: An analysis of the Content of Verbal Protocols
IEEE Trans on Systems, Man, Cybernetics, 1986Slide55
outline
mental modelstypesmodelsconventions & “discourse rules”
expertise effects
tool implications
interesting tools
55Slide56
outline
mental modelstypesmodelsconventions & “discourse rules”
expertise effects
tool implications
interesting tools
56Slide57
tool implications
browsing supportbrowse from high to low level and low to high levelsearchinglooking for snippets by analogymultiple views
show orthogonal object relationships
context-driven views
determine best view based on context
additional cognitive support
external devices to support cognitive tasks needed
57
Margaret-Anne
Storey
Theories, Methods, and Tools in Program Comprehension: Past, Present, and Future
Int. Workshop on Program Comprehension, 2005Slide58
tool implications
browsing supportbrowse from high to low level and low to high levelsearching
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
58
Margaret-Anne
Storey
Theories, Methods, and Tools in Program Comprehension: Past, Present, and Future
Int. Workshop on Program Comprehension, 2005Slide59
browsing support
traverse control and data flow pathsswitching between top-down and bottom-up modelsbreadth-first and depth-first
59Slide60
tool implications
browsing supportbrowse from high to low level and low to high levelsearching
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
60
Margaret-Anne
Storey
Theories, Methods, and Tools in Program Comprehension: Past, Present, and Future
Int. Workshop on Program Comprehension, 2005Slide61
tool implications
browsing supportbrowse from high to low level and low to high levelsearchinglooking 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
61
Margaret-Anne
Storey
Theories, Methods, and Tools in Program Comprehension: Past, Present, and Future
Int. Workshop on Program Comprehension, 2005Slide62
searching
search for code snippetsnot just by textexample: query the role of a variable, when a function is calleduseful for top-down hypothesis testing
62Slide63
tool implications
browsing supportbrowse from high to low level and low to high levelsearchinglooking 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
63
Margaret-Anne
Storey
Theories, Methods, and Tools in Program Comprehension: Past, Present, and Future
Int. Workshop on Program Comprehension, 2005Slide64
tool implications
browsing supportbrowse from high to low level and low to high levelsearching
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
64
Margaret-Anne
Storey
Theories, Methods, and Tools in Program Comprehension: Past, Present, and Future
Int. Workshop on Program Comprehension, 2005Slide65
multiple views
multiple ways of viewing programscall graphobject hierarchyetc.different views are applicable for different tasks
65Slide66
tool implications
browsing supportbrowse from high to low level and low to high levelsearching
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
66
Margaret-Anne
Storey
Theories, Methods, and Tools in Program Comprehension: Past, Present, and Future
Int. Workshop on Program Comprehension, 2005Slide67
tool implications
browsing supportbrowse from high to low level and low to high levelsearching
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
67
Margaret-Anne
Storey
Theories, Methods, and Tools in Program Comprehension: Past, Present, and Future
Int. Workshop on Program Comprehension, 2005Slide68
context-driven views
alter views based on program metricssize of programinterdependence of modulesflatness of hierarchyetc.
68Slide69
tool implications
browsing supportbrowse from high to low level and low to high levelsearching
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
69
Margaret-Anne
Storey
Theories, Methods, and Tools in Program Comprehension: Past, Present, and Future
Int. Workshop on Program Comprehension, 2005Slide70
tool implications
browsing supportbrowse from high to low level and low to high levelsearching
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
70
Margaret-Anne
Storey
Theories, Methods, and Tools in Program Comprehension: Past, Present, and Future
Int. Workshop on Program Comprehension, 2005Slide71
additional cognitive support
experts:tools to support cognitive tasksexternal devicesscratchpadsnovicespedagogical support
programming language
task domain
71Slide72
outline
mental modelstypesmodelsconventions & “discourse rules”
expertise effects
tool implications
interesting tools
72Slide73
outline
mental modelstypesmodelsconventions & “discourse rules”
expertise effects
tool implications
interesting tools
73Slide74
structured editors
reduce burden or memorizing syntaxfocus 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 Slide75Slide76Slide77
literate programming
source code interwoven with exposition of logic, like an essayallows programmers to work top-down or bottom-up
77
D. Knuth
Literate Programming
Journal of Computer & Information Sciences, 1979Slide78
78
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, 1979Slide79
conclusion
beginners start off with an incomplete mental model for how code worksexperts are better at code comprehension because they focus on higher level patternspatterns can be considered “discourse rules”naming conventions, design patterns, schemasexperts work significantly better when reading & writing code according to these patterns
79Slide80
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?
80Slide81
references - 1
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
B.
Shneiderman
and 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
81Slide82
references - 2
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
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
82Slide83
does visual programming help?
83
C.
Hundhausen
, S. Douglas, J.
Stasko
A meta-study of algorithm
visualization effectiveness
Journal of Visual Languages & Computing, 2002Slide84
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!
84Slide85
why does it matter?
reading code is done when:searching for relevant codere-acquainting oneself with a projectreading someone else’s coderefactoring
…
85Slide86
the gist of the talk
beginners start off with an incomplete mental model for how code worksexperts are better at code comprehension because they focus on higher level patternspatterns can be considered “discourse rules”naming conventions, design patterns, schemasexperts work significantly better when reading & writing code according to these patterns
86Slide87
87
var
Dict
=
function
() {
this
.
keys
= [];
this
.
values
= [];
};
Dict.prototype.set
=
function
(key, value) {
var
keyIndex
=
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)
return
this
.values
[
keyIndex
];
return
undefined
;
};Slide88
mental models
top-down models1st: hypothesize about code
2
nd
: check hypotheses
start on a high level, dig in
bottom-up models
1
st
: read code statements
2
nd
: mental chunking
start on a low level, ascend
88
hybrid models
incorporate elements from both, based on the situationSlide89
shneiderman &
mayer’s modelsemantic knowledge: general programming conceptslow-level knowledge,
e.g. what assignments do
high-level knowledge
, e.g. algorithms
syntactic knowledge:
programming language details
sometimes overlaps across programming langs.
89
B.
Shneiderman
and R. Mayer
Syntactic/Semantic Interactions in Programmer Behavior: A Model and Experimental
Results
Journal of Computer & Information Sciences, 1979Slide90
brooks’ model
“top-down”analyze code on a high level, then look at specificsargues that programmers form a series of hypothesesbeacons help verify or reject these hypotheses
90
R. Brooks
Towards a theory of the comprehension of computer programs
International J. on Man-Machine Studies, 1981Slide91
containers & paths
91
B.
Liblit
, A.
Begel
, and E.
Sweetser
Cognitive Perspectives on the Role of Naming in Computer Programs
Psychology of Programming Interest Group, 2006Slide92
polysemy, homonymy, & overloading
92
B.
Liblit
, A.
Begel
, and E.
Sweetser
Cognitive Perspectives on the Role of Naming in Computer Programs
Psychology of Programming Interest Group, 2006