ALIGNING DEVELOPMENT TOOLS

WITH THE WAY PROGRAMMERS THINK

ABOUT CODE CHANGES

Presentation type: paper reviewClass: CS 584 – Human Aspects of Programming Languages

Presenter: Sergii ShmarkatiukDate: 10/15/2013

2

MOTIVATION

Developers need to perform many similar source code editing operations that could

be grouped and executed at once

3

MOTIVATION

But there is no suitable tool that would allow to do that in an intuitive, consistent

and error-free manner

4

EXISTING APPROACHES

Text-based toolsRegular expressionsSED + AWK

IDE based toolsStandard ‘search and replace’ functionalityRefactoring features

Structure-based source code manipulation tools (abstract syntax tree visualization)A*TAWKStratego/XT

5

DISADVANTAGES OF EXISTING APPROACHES

Regular expressions

SED + AWK

IDE-based refactoring

IDE-based ‘search and replace’

AST-based tools

Difficult to read and understand Powerful, but even more difficult to read and understand

Does not allow to create custom transformations

Treats source code as a flat, structureless text

Difficult to understand

6

PROPOSED SOLUTION

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

Design and implementation of visual tool based on following principles:

7

EXAMPLE. STEP 1

8

EXAMPLE. STEP 2

9

EXAMPLE. STEP 3

10

EXAMPLE. STEP 4

11

EXAMPLE. STEP 5

12

METHODOLOGY Clear definition of goal (source code

transformations generation) and target audience (experienced Java-developers)

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

13

COMPARISON WITH ANOTHER EXISTING SOLUTION

Works by default in Eclipse, IntelliJ IDEA, NetBeans, Visual Studio, Notepad++, SciTE, UltraEdit, …

Language-agnostic approach

Powerful and flexible Possibility of rollback

Regular expressions are difficult to read and understand

Special syntax for matches reference

Different implementations in different tools

Advantages Disadvantages

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

14

SHORT DEMO

15

INSIGHT/IDEA

Two approaches could be integrated

1. Apply edit-by-example principle to generate RegExp

2. Add functionality for handling RegExp block references

var1 & var2

(\w*) & (\w*)firstMatch secondMatch

(\w*) & (\w*)

~(~\1 | ~\2)firstMatchsecondMatch

to regexp

transformation

16

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

17

QUESTION GROUPS

Evaluation Regular expressions

End-user mindset

Experts vs non-

experienced programmers

Real source maintenance

concernsOther

18

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?

19

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?

20

QUESTIONS: END-USER MINDSET

Jun Xie: In the paper, there is one statement: This design allows programmers to perform direct-manipulation 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?

21

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?

22

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?