CS 584 - Aligning development tools with the way programmers think about code changes
Download as PPTX, PDF0 likes792 views
This presentation reviews a proposed visual tool for generating source code transformations based on the edit-by-example principle. The tool aims to address limitations of existing approaches like regular expressions, IDE search/replace, and AST-based tools by allowing programmers to intuitively create custom transformations through direct manipulation of code representations. An initial prototype was implemented and evaluated via a user study, which provided insights for future iterations. The tool combines textual and graphical elements to naturally fit programmers' mental models of code structure.
CS 584 - Aligning development tools with the way programmers think about code changes
- 1. 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
- 2. MOTIVATION Developers need to perform many similar source code editing operations that could be grouped and executed at once 2
- 3. MOTIVATION But there is no suitable tool that would allow to do that in an intuitive, consistent and error-free manner 3
- 4. 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
- 5. 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
- 6. 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
- 12. 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
- 13. 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
- 14. SHORT DEMO 14
- 15. 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
- 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 16
- 17. QUESTION GROUPS Evaluation Regular expressions End-user mindset Experts vs nonexperienced programmers Real source maintenance concerns Other 17
- 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? 18
- 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? 19
- 20. 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
- 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? 21
- 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? 22