Nicholas Chen

Is it dangerous to use version control histories to study source code evolution

Researchers use file-based Version Control System (VCS) as the primary source of code evolution data. VCSs are widely used by developers, thus, researchers get easy access to historical data of many projects. Although it is convenient, research based on VCS data is incomplete and imprecise. Moreover, answering questions that correlate code changes with other activities (e.g., test runs, refactoring) is impossible. Our tool, CodingTracker, non-intrusively records fine-grained and diverse data during code development. CodingTracker collected data from 24 developers: 1,652 hours of development, 23,002 committed files, and 314,085 testcase runs. This allows us to answer: How much code evolution data is not stored in VCS? How much do developers intersperse refactorings and edits in the same commit? How frequently do developers fix failing tests by changing the test itself? How many changes are committed to VCS without being tested? What is the temporal and spacial locality of changes?

A comparative study of manual and automated refactorings

Despite the enormous success that manual and automated refactoring has enjoyed during the last decade, we know little about the practice of refactoring. Understanding the refactoring practice is important for developers, refactoring tool builders, and researchers. Many previous approaches to study refactorings are based on comparing code snapshots, which is imprecise, incomplete, and does not allow answering research questions that involve time or compare manual and automated refactoring. We present the first extended empirical study that considers both manual and automated refactoring. This study is enabled by our algorithm, which infers refactorings from continuous changes. We implemented and applied this algorithm to the code evolution data collected from 23 developers working in their natural environment for 1,520 hours. Using a corpus of 5,371 refactorings, we reveal several new facts about manual and automated refactorings. For example, more than half of the refactorings were performed manually. The popularity of automated and manual refactorings differs. More than one third of the refactorings performed by developers are clustered in time. On average, 30% of the performed refactorings do not reach the Version Control System.

Drag-and-drop refactoring: intuitive and efficient program transformation

Refactoring is a disciplined technique for restructuring code to improve its readability and maintainability. Almost all modern integrated development environments (IDEs) offer built-in support for automated refactoring tools. However, the user interface for refactoring tools has remained largely unchanged from the menu and dialog approach introduced in the Smalltalk Refactoring Browser, the first automated refactoring tool, more than a decade ago. As the number of supported refactorings and their options increase, invoking and configuring these tools through the traditional methods have become increasingly unintuitive and inefficient. The contribution of this paper is a novel approach that eliminates the use of menus and dialogs altogether. We streamline the invocation and configuration process through direct manipulation of program elements via drag-and-drop. We implemented and evaluated this approach in our tool, Drag-and-Drop Refactoring (DNDRefactoring), which supports up to 12 of 23 refactorings in the Eclipse IDE. Empirical evaluation through surveys and controlled user studies demonstrates that our approach is intuitive, more efficient, and less error-prone compared to traditional methods available in IDEs today. Our results bolster the need for researchers and tool developers to rethink the design of future refactoring tools.

Expressing pipeline parallelism using TBB constructs: a case study on what works and what doesn't

Task-based libraries such as Intels Threading Building Blocks (TBB) provide higher levels of abstraction than threads for parallel programming. Work remains, however, to determine how straightforward it is to use these libraries to express various patterns of parallelism. This case study focuses on a particular pattern: pipeline parallelism. We attempted to transform three representative pipeline applications - content-based image retrieval, compression and video encoding - to use the pipeline constructs in TBB. We successfully converted two of the three applications. In the successful cases we discuss our transformation process and contrast the expressivity and performance of our implementations to existing Pthreads versions; in the unsuccessful case, we detail what the challenges were and propose possible solutions.

The need for richer refactoring usage data

Even though modern Integrated Development Environments (IDEs) support many refactorings, studies suggest that automated refactorings are used infrequently, and few developers use anything beyond Rename and Extract refactorings. Little is known about why automated refactorings are seldom used. We present a list of challenging questions whose answers are crucial for understanding the usability issues of refactoring tools. This paper argues that the existing data sources - Eclipse UDC, Eclipse refactoring histories, version control histories, etc. - are inadequate for answering these questions. Finally, we introduce our tools to collect richer usage data that will enable us to answer some of the open research questions about the usability of refactoring tools. Findings from our data will foster the design of the next generation of refactoring tools.

Toward refactoring in a polyglot world: extending automated refactoring support across Java and XML

Many automated refactoring tools only work with one programming language. However, most complex programs rely on polyglot programming --- entailing the use of different programming languages, libraries and frameworks. While finding a general solution for extending refactoring across multiple languages is hard, it is simple and possible to support automated refactorings for some common cases that programmers already encounter in their programs today. Supporting those common cases is essential in encouraging programmers to make changes that would increase the understandability and maintainability of their programs. This paper is a step toward encouraging tool developers to think about supporting multi-language refactorings. We present our tool for supporting multi-language refactorings from studying the interactions between Java and XML configuration files. Our tool extends Rename Refactoring support across three different popular Java frameworks: Struts, Hibernate and Spring.

JFlow: practical refactorings for flow-based parallelism

Emerging applications in the domains of recognition, mining and synthesis (RMS); image and video processing; data warehousing; and automatic financial trading admit a particular style of parallelism termed flow-based parallelism. To help developers exploit flow-based parallelism, popular parallel libraries such as Groovys GPars, Intels TBB Flow Graph and Microsofts TPL Dataflow have begun introducing many new and useful constructs. However, to reap the benefits of such constructs, developers must first use them. This involves refactoring their existing sequential code to incorporate these constructs - a manual process that overwhelms even experts. To alleviate this burden, we introduce a set of novel analyses and transformations targeting flow-based parallelism. We implemented these ideas in JFlow, an interactive refactoring tool integrated into the Eclipse IDE. We used JFlow to parallelize seven applications: four from a previously known benchmark and three from a suite of large open source projects. JFlow, with minimal interaction from the developer, can successfully parallelize applications from the aforementioned domains with good performance (offering up to 3.45x speedup on a 4-core machine) and is fast enough to be used interactively as part of a developers workflow.

Patterns for cache optimizations on multi-processor machines

Writing parallel programs that run optimally on multi-processor machines is hard. Programmers not only have to reason about existing cache issues that affect single-threaded programs but also new cache issues that impact multi-threaded programs. Such cache issues are surprisingly common; neglecting them leads to poorly performing programs that do not scale well. We illustrate these common cache issues and show how current tools aid programmers in reliably diagnosing these issues. The goal of our work is to promote discussions on whether such cache issues should be included in the Berkeley Our Pattern Language --- either by incorporating such performance issues directly into each pattern as forces or by creating a supplementary pattern language for general performance optimizations.

A pattern language for screencasting

Many activities --- especially software related ones --- are more easily learned by observing a mentor as he performs the activity. However, such opportunities for observations are hard to come by and are usually infeasible when there are many participants who are interested. Fortunately, the ubiquity of video sharing sites has spawned numerous screencasts that address this teaching-learning problem. Our pattern language for screencasting proposed here assists the mentor in preparing high-quality screencasts in as little time and effort as possible.

The language of languages research project: unifying concepts expressed across different notations

Maintaining the consistency of multiple notations used in large projects is daunting. Language of Languages(LoLs) is our experimental language workbench that fulfills a frequently overlooked but important role: unify the different notations so developers can better understand and evolve a project. Due to the impossibility of anticipating all the notations that may be used in a project, LoLs adopts a language agnostic view and supports different notations from free-form text to graphical forms and shapes. Our demo begins by illustrating the fundamental ideas of LoLs through building a calculator that supports multiple notations; the demo concludes with more advanced projects that exemplify the extent of our multi-notation support.