When many clones are detected in software programs, not all clones are equally important to developers. To help developers refactor code and improve software quality, various tools were built to recommend clone-removal refactorings based on the past and the present information, such as the cohesion degree of individual clones or the co-evolution relations of clone peers. The existence of these tools inspired us to build an approach that considers as many factors as possible to more accurately recommend clones. This paper introduces CREC, a learning-based approach that recommends clones by extracting features from the current status and past history of software projects. Given a set of software repositories, CREC first automatically extracts the clone groups historically refactored (R-clones) and those not refactored (NR-clones) to construct the training set. CREC extracts 34 features to characterize the content and evolution behaviors of individual clones, as well as the spatial, syntactical, and co-change relations of clone peers. With these features, CREC trains a classifier that recommends clones for refactoring. We designed the largest feature set thus far for clone recommendation, and performed an evaluation on six large projects. The results show that our approach suggested refactorings with 83% and 76% F-scores in the within-project and cross-project settings. CREC significantly outperforms a state-of-the-art similar approach on our data set, with the latter one achieving 70% and 50% F-scores. We also compared the effectiveness of different factors and different learning algorithms.

A (build) target specifies the information that is needed to automatically build a software artifact. This paper focuses on underutilized targets - an important dependency problem that we identified at Google. An underutilized target is one with files not needed by some of its dependents. Underutilized targets result in less modular code, overly large artifacts, slow builds, and unnecessary build and test triggers. To mitigate these problems, programmers decompose underutilized targets into smaller targets. However, manually decomposing a target is tedious and error-prone. Although we prove that finding the best target decomposition is NP-hard, we introduce a greedy algorithm that proposes a decomposition through iterative unification of the strongly connected components of the target. Our tool found that 19,994 of 40,000 Java library targets at Google can be decomposed to at least two targets. The results show that our tool is (1) efficient because it analyzes a target in two minutes on average and (2) effective because for each of 1,010 targets, it would save at least 50% of the total execution time of the tests triggered by the target.

Static analysis tools report software defects that may or may not be detected by other verification methods. Two challenges complicating the adoption of these tools are spurious false positive warnings and legitimate warnings that are not acted on. This paper reports automated support to help address these challenges using logistic regression models that predict the foregoing types of warnings from signals in the warnings and implicated code. Because examining many potential signaling factors in large software development settings can be expensive, we use a screening methodology to quickly discard factors with low predictive power and cost-effectively build predictive models. Our empirical evaluation indicates that these models can achieve high accuracy in predicting accurate and actionable static analysis warnings, and suggests that the models are competitive with alternative models built without screening.

Static analysis tools for software defect detection are becoming widely used in practice. However, there is little public information regarding the experimental evaluation of the accuracy and value of the warnings these tools report. In this paper, we discuss the warnings found by FindBugs, a static analysis tool that finds defects in Java programs. We discuss the kinds of warnings generated and the classification of warnings into false positives, trivial bugs and serious bugs. We also provide some insight into why static analysis tools often detect true but trivial bugs, and some information about defect warnings across the development lifetime of software release. We report data on the defect warnings in Sun's Java 6 JRE, in Sun's Glassfish JEE server, and in portions of Google's Java codebase. Finally, we report on some experiences from incorporating static analysis into the software development process at Google.

Restructuring software to improve its design can lower software maintenance costs. One problem encountered during restructuring is formulating the new design. A meaning-preserving program restructuring tool with a star diagram manipulable visualization can help a programmer redesign a program based on abstract data types. However, the transformational support required for meaning-preserving restructuring is costly to provide. Also, programmers encounter comprehension and recall difficulties in complex restructuring tasks. Consequently, transformations were replaced with visual and organizational aids that help a programmer to plan and carry out a complex restructuring. For example, a star diagram manipulation called trimming was added, which mimics the way that basic restructuring transformations affect the star diagram display, allowing a programmer to plan a restructuring without depending upon restructuring transformations. With the ability to annotate trimmed star diagram components, plans can be recorded and later recalled. Programmer-controlled elision was added to help remove clutter from star diagram views. We implemented a star diagram planning tool for C programs, measured its elision capabilities, and performed a programmer study. We found that elision is effective in controlling star diagram size, and the study revealed that each programming team successfully planned its restructuring in rather different, unanticipated ways. These experiments resulted in important improvements in the tool's software design and user interface.

Restructuring software to improve its design can lower software maintenance costs. One problem in carrying out such a restructuring is planning the new detailed design. The star diagram manipulable visualization can help a programmer redesign a program based on abstract data types. However, our measurements revealed that the view can be too large for a programmer to effectively assimilate. Also, design plans can be expressed only by restructuring, although our studies revealed that it is beneficial to preplan a restructuring. Finally, the tool user can build a star diagram for only a single data structure, although an abstract data type might actually have several components or have multiple instantiations.Exploiting basic properties of the star diagram can mitigate these problems. First, programmer-controlled elision can remove clutter from the star diagram view. Second, elision and annotation of star diagram components can mimic restructuring, thereby supporting the planning of a restructuring. Such support also allows for the planning of a non-restructuring maintenance task. Finally, to dynamically control what data structures are visualized, the tool user can union star diagrams.We built a star diagram planning tool for C programs, measured its elision capabilities, and performed a programmer study for the encapsulation of a widely-used data structure in a 28,000 line program. We found that the amount of elision can be substantial, but is not always adequate. In the study we found that each programming team successfully planned their restructuring in rather different, unanticipated ways.