CS 584 - Aligning development tools with the way programmers think about code changes

ALIGNING DEVELOPMENT
TOOLS WITH THE WAY
PROGRAMMERS THINK
ABOUT CODE CHANGES
Presentation type: paper review
Class: CS 584 – Human Aspects of Programming Languages
Presenter: Sergii Shmarkatiuk
Date: 10/15/2013

MOTIVATION

Developers need to perform many similar
source code editing operations that could
be grouped and executed at once

2

MOTIVATION

But there is no suitable tool that would
allow to do that in an intuitive, consistent
and error-free manner

3

EXISTING APPROACHES
 Text-based



Regular expressions
SED + AWK

 IDE



tools

based tools

Standard ‘search and replace’ functionality
Refactoring features

 Structure-based

source code manipulation
tools (abstract syntax tree visualization)




A*
TAWK
Stratego/XT

4

DISADVANTAGES OF EXISTING
APPROACHES
Regular expressions Difficult to read and
understand
Powerful, but even more
 SED + AWK
difficult to read and understand








IDE-based
refactoring

Does not allow to create custom
transformations

IDE-based ‘search
and replace’

Treats source code as a flat,
structureless text

AST-based tools

Difficult to understand

5

PROPOSED SOLUTION

Design and implementation of visual tool
based on following principles:
Combination of textual and graphical elements
 From-example construction and iterative
refinement approach (based on edit-by-example
principle)
 Intuitive representation, which naturally fits into
the programmers’ perception of the source code
 Assisting developers with creating and
manipulating transformations
 Early errors detection and correction


6

METHODOLOGY
Clear definition of goal (source code transformations
generation) and target audience (experienced Javadevelopers)
 Prototype implementation
 3 iterations of prototype verification based on
compliance with Cognitive Dimensions
 Empirical study with few target audience
representatives








Pre-study interview
Training session
Code-editing task
Post-study interview based on Cognitive Dimensions
questionnaire optimized for users
Evaluation of study results using Cognitive Dimensions
framework

12

COMPARISON WITH ANOTHER
EXISTING SOLUTION

RegExp-based ‘search and replace’ in IDEs and
popular text editors
Advantages

Works by default in
Eclipse, IntelliJ IDEA,
NetBeans, Visual
Studio, Notepad++,
SciTE, UltraEdit, …
 Language-agnostic
approach
 Powerful and flexible
 Possibility of rollback


Disadvantages

Regular expressions
are difficult to read
and understand
 Special syntax for
matches reference
 Different
implementations in
different tools


13

INSIGHT/IDEA

Two approaches could be integrated
1. Apply edit-by-example principle to generate
RegExp
var1 & var2

to regexp

(w*) & (w*)

2. Add functionality for handling RegExp block
references
firstMatch

secondMatch

(w*) & (w*)

transformation

firstMatch secondMatch

~(~1 | ~2)

15

INSIGHTS/IDEAS

FOR MY PROJECT

 Application

of similar methodology
 Combination of textual, graphic and UI
elements
 Study of target users’ perception/intuition
 Application of Cognitive Dimensions
framework
 Extension of edit-by-example approach

16

QUESTION GROUPS

Evaluation

Regular
expressions

End-user
mindset

Experts vs nonexperienced
programmers

Real source
maintenance
concerns

Other

17

QUESTIONS:

EVALUATION

Zhang, Chaoqiang: I am a little bit surprised that the
evaluation part of this part only has treatment group and
no control group. In my mind, if they could have another
group to use sed utility(maybe give them a little bit
training) and see if they could finish the task better, and
the comparison of these two groups maybe make the
evaluation more convincing
Mihai Codoban: The evaluation does not compare how
much better iXj is in comparison to existing techniques
(refactorings, “errors as todos”, etc). Does this disqualify
the authors’ statements that iXj is easier, faster and more
intuitive than current approaches? Is it just a fancy
language aware regular expression editor?

18

QUESTIONS: REGULAR EXPRESSIONS




Zhang, Chaoqiang: I am sort of concerned
about this language's expressive power. Can it
generally express any regular expression? If it is
not, maybe expert programmers (the target users
of this language) would prefer polishing their
regular expression skill to learning this tool?
Michael Mendes: Do you think future versions
of this tool should be IDE-independent, and why?

19

QUESTIONS:




END-USER MINDSET

Jun Xie: In the paper, there is one statement: This
design allows programmers to perform directmanipulation of a representation that aligns well
with their mental model of source code. What is the
programmers' mental model of source code?
Michael Slater: I looked through this paper and
couldn't find any listing of the programmers' mental
models that were used to compare to the
representations of the tool. I could see the basic Java
code structure in the paper, but that was it. Is this
paper claiming that programmers think of their
software only in terms of the structures Java offers?
Can we legitimately claim anything regarding
programmers' mental models when the programmers
didn't know the source code used in the study?

20

QUESTIONS:

EXPERTS VS NON-

EXPERTS





Catharina Vijay: How could iXj help people less
experienced at code maintenance?
Wojtek Rajski: I understand that iXj has experts in
mind. But novice programmers will sometimes realize
during the build process that they have to change
how a fundamental part of the code works. How
would the requirements for CDs change for
intermediate level programmers?
Krishna Pratik: I believe expert programmers would
not be good participants as they might
unintentionally portray using the tool as being too
simple to use for code transformations. To better test
the utility of the application, shouldn't the study be
conducted by novice-middle experienced
programmers?

21

QUESTIONS:

OTHER

William Jernigan: What can we do as study
designers to avoid situations where participants
may diverge from the expected behavior like
Boshernitsan et al experience, cited in the
Metrics section where the authors say: “two
participants decided to perform several
transformations that were not on the list,
because they ‘seemed appropriate.” ?
 William Jernigan: In the beginning stages of
the design process, Boshernitsan et al studied
development/change logs for TEX, XEmacs, and a
transcript from Martin and Koss. How specific
are these change logs to the design they wanted
to achieve? How do we determine what to review
and study when creating a design besides the
specific user for whom we are designing?


22

CS 584 - Aligning development tools with the way programmers think about code changes

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to CS 584 - Aligning development tools with the way programmers think about code changes (20)

More from Sergii Shmarkatiuk (10)

Recently uploaded (20)

CS 584 - Aligning development tools with the way programmers think about code changes