Integrated Development Environments (IDEs) provide a convenient standalone solution that supports developers during various phases of software development. In order to provide better support for developers within such IDEs, we need to understand how developers use them. To infer useful conclusions, such information should be gathered for different types of IDEs, for different programming languages, and in different development settings.

In this paper, we present FEEDBAG, an extension for Visual Studio that tracks developers’ interactions with the IDE. FEED-BAG generates a rich stream of interaction events and provides means for developers to review and submit the data to a server. We recently used the tool in a study, recording more than 6,300 hours of work time. Future studies with different user groups are needed to explore and compare IDE-usage aspects, like code-comprehension assistance, in detail. Therefore, we publish FEEDBAG and encourage other researchers to use it as well.

Given different ways to fix a failure in a program run, you may want to fix it such that future runs of the same

Programmers use diverse tools for code understanding to access various types of context information like interface definitions, revision histories, and debugging values. Integrated development environments support specialized visualization mechanisms for such context types. While these mechanisms in principle enable programmers to access required information, the diversity of visualizations as well as the distance between code locations and related information may slow down development. We present a generic approach to embed various types of context uniformly into the main source code view in close proximity to the relevant source code by using a concept called code portals. Furthermore, embedded content can be organized and manipulated directly using operations already familiar to programmers. We illustrate the approach using different types of context, and present preliminary results of a qualitative study indicating that our approach is usable and improves program comprehension and productivity in general. The approach is implemented in a prototypical source code editor.

Web developers face some unique challenges when trying to understand, modify and document the structure of their web applications. The heterogeneity and complexity of the underlying technologies and languages heighten comprehension problems. In particular, JavaScript, as an essential part of the Web ecosystem, is a language that offers a flexibility that can make its code hard to grasp, when it comes to comprehension and documentation tasks. In this paper, we present the first iteration of WAVI (WebAppViewer), a reverse engineering tool that uses static analysis and a filter-based mechanism to retrieve and document the structure of a Web application. WAVI is able to extract elements coming from essential web languages and frameworks such as HTML, JavaScript, CSS and Node.js. The tool makes use of some simple, effective heuristics to accurately retrieve dependency links for files and methods. WAVI also offers the visualisation of the extracted information as force-directed graphs and customized class diagrams. The effectiveness of WAVI is evaluated with experiments that demonstrate that (i) it can resolve JavaScript calls better than a recent technique, and (ii) its visualisation modules are intuitive and scalable.

This paper presents PORBS, a parallelised observation-based slicing tool. The tool itself is written in Java making it platform independent and leverages the build chain of the system being sliced to avoid the need to replicate complex compiler analysis. The target audience of PORBS is software engineers and researchers working with and on tools and techniques for software comprehension, debugging, re-engineering, and maintenance.

Static textual analysis techniques have been recently applied to process and synthesize source code. The underlying tenet is that important information is embedded in code identifiers and internal code comments. Such information can be analyzed to provide automatic aid for several software engineering activities. To facilitate this line of work, we present STAC, a tool for supporting Static Textual Analysis of Code. STAC is designed as a light-weight stand-alone tool that provides a practical one-stop solution for code indexing. Code indexing is the process of extracting important textual information from source code. Accurate indexing has been found to significantly influence the performance of code retrieval and analysis methods. STAC provides features for extracting and processing textual patterns found in Java, C++, and C# code artifacts. These features include identifier splitting, stemming, lemmatization, and spell-checking. STAC is also provided as an API to help researchers to integrate basic code indexing features into their code.

Methods not having side effects (pure methods) are beneficial in some situations. For example, data race does not occur among pure methods in multi-thread programs. Another example is that there are some cases where developers expect methods are pure, such as equals, hashCode, and getter methods in Java. This paper presents a tool finding code changes where methods become pure/impure. This tool can prevent developers from inducing purity-related bugs to methods. The authors have applied the tool to two open source systems and found (1) a dozen of methods moved to pure/impure repeatedly and (2) there were many cases where purity of methods had changed without code changes.

Software becomes increasingly complex with its continuous maintenance activities. Given a system under maintenance, developers used to employing code search techniques to locate the code of their interests. However, they may have difficulties in understanding the source code elements and the relationship among them in the searching results. If there is a word base for a specific system, the developers can refer it to help locate and recover the source code elements and their relationships, which can improve the maintenance efficiency. In this paper, we present a tool, WB4SP(Word Base for Specific Programs), which focuses on building the word base for a specific system. WB4SP can retrieve the words, recover the relationship between them, and display the evolution of these words during the software evolution.

The Eclipse framework is a popular and widely adopted framework that has been evolving for over a decade. Like many other evolving software systems, the Eclipse framework provides both stable and supported interfaces (APIs) and unstable, discouraged, and unsupported interfaces (non-APIs). However, despite being discouraged by Eclipse, the usage of bad interfaces is not uncommon. Our previous research has confirmed that as Eclipse states, indeed APIs are stable while non-APIs are unstable. Applications using non-APIs face compatibility challenges in new Eclipse releases. Furthermore, our previous studies further revealed that the reason why application developers use the unstable interfaces is because they cannot find stable interfaces with the functionality that they require. Moreover, in a study we conducted, Eclipse application developers stated that they manually find the functionality from Eclipse. Eclipse being a very large complex software system with a large number of committers, we hypothesize that as developers manually search for the functionality they they require, it is possible that they miss stable interfaces offering the same functionality. To this end, using code clone detection techniques, we analyzed 18 major releases of Eclipse for possible clones. Our findings are three fold: i) we discover that indeed there exist clones in Eclipse, ii) we also discovered that some of the identified clones originate from different Eclipse projects, iii) our findings reveal that there is no significant number of APIs (less than 1%) offering the same or similar functionality as the non-APIs in all Eclipse releases we studied. This reveals that there are very few syntactic clones between API and non-API, thus developers were forced to either use non-API or find an API that exists, that is similar in functionality, but not in syntax.

Software developers need to cope with the complexity of Application Programming Interfaces (APIs) of external libraries or frameworks. Typical APIs provide thousands of methods to their client programs, and these methods are not used independently of each other. Much existing work has provided different techniques to mine API usage patterns based on client programs in order to help developers understanding and using existing libraries. Other techniques propose to overcome the strong constraint of clients’ dependency and infer API usage patterns only using the library source code. In this paper, we propose a cooperative usage pattern mining technique (COUPminer) that combines client-based and library-based usage pattern mining. We evaluated our technique through four APIs and the obtained results show that the cooperative approach allows taking advantage at the same time from the precision of client-based technique and from the generalizability of library-based techniques.

Truck Factor (TF) is a metric proposed by the agile community as a tool to identify concentration of knowledge in software development environments. It states the minimal number of developers that have to be hit by a truck (or quit) before a project is incapacitated. In other words, TF helps to measure how prepared is a project to deal with developer turnover. Despite its clear relevance, few studies explore this metric. Altogether there is no consensus about how to calculate it, and no supporting evidence backing estimates for systems in the wild. To mitigate both issues, we propose a novel (and automated) approach for estimating TF-values, which we execute against a corpus of 133 popular project in GitHub. We later survey developers as a means to assess the reliability of our results. Among others, we find that the majority of our target systems (65%) have TF ≤ 2. Surveying developers from 67 target systems provides confidence towards our estimates; in 84% of the valid answers we collect, developers agree or partially agree that the TF’s authors are the main authors of their systems; in 53% we receive a positive or partially positive answer regarding our estimated truck factors.

There are a number of experiments that show a benefit for statically typed programming languages. However, it is unclear whether these results are mainly driven by the expectations that developers do benefit from static type systems, i.e. whether the results reflect on the experimenters’ bias. From that perspective, it seems consequent to design an experiment that tries to reveals the opposite: to enforce a benefit for dynamically typed languages. This paper describes an experiment that tries to enforce such a benefit for dynamically typed languages in an experimental setting. Four (quite artificial) tasks were designed from which the experimenters expected to measure a clear benefit for dynamically typed languages. However, only in two cases such a benefit could be measured. What is even more interesting is that two other tasks (again, explicitly designed to show a benefit for dynamically typed languages) showed the opposite.

Identifying similar code in software systems can assist many software engineering tasks such as program understanding and software refactoring. While most approaches focus on identifying code that looks alike, some techniques aim at detecting code that functions alike. Detecting these functional clones — code that functions alike — in object oriented languages remains an open question because of the difficulty in exposing and comparing programs’ functionality effectively. We propose a novel technique, In-Vivo Clone Detection, that detects functional clones in arbitrary programs by identifying and mining their inputs and outputs. The key insight is to use existing workloads to execute programs and then measure functional similarities between programs based on their inputs and outputs, which mitigates the problems in object oriented languages reported by prior work. We implement such technique in our system, HitoshiIO, which is open source and freely available. Our experimental results show that HitoshiIO detects more than 800 functional clones across a corpus of 118 projects. In a random sample of the detected clones, HitoshiIO achieves 68+% true positive rate with only 15% false positive rate.

Detecting similar applications is a challenging problem, since it implies that similar high-level features and their low-level implementations can be detected and matched automatically. We propose an approach for automatically detecting Closely reLated applications in ANdroid (CLANdroid) by relying on advanced Information Retrieval techniques and five semantic anchors: identifiers, Android APIs, intents, permissions, and sensors. To evaluate CLANdroid we created a benchmark consisting of 14,450 apps along with information on similar apps provided by Google Play. We also compared effectiveness of different semantic anchors for detecting similar apps as perceived by 27 users. The results show that using Android-specific semantic anchors are useful for detecting similar Android apps across different categories. We also measured the impact of third-party libraries and obfuscated code when identifying similar Android apps, and our results suggest that there is significant difference in the accuracy when third-party libraries are excluded.

Code clones are prevalent in software systems due to many factors in software development. Detecting code clones and managing consistency between them along code evolution can be very useful for reducing clone-related bugs and maintenance costs. Despite some early attempts at detecting code clones and managing the consistency between them, the state-of-the-art tool can only handle simple code clones whose structures are identical or quite similar. However, existing empirical studies show that clones can have quite different structures with their evolution, which can easily go beyond the capability of the state-of-the-art tool. In this paper, we propose CCSync, a novel, rule-directed approach, which paves the structure differences between the code clones and synchronizes them even when code clones become quite different in their structures. The key steps of this approach are, given two code clones, to (1) extract a synchronization rule from the relationship between the clones, and (2) once one code fragment is updated, propagate the modifications to the other following the synchronization rule. We have implemented a tool for CCSync and evaluated its effectiveness on five Java projects. Our results shows that there are many code clones suitable for synchronization, and our tool achieves precisions of up to 92% and recalls of up to 84%. In particular, more than 76% of our generated revisions are identical with manual revisions.

In this paper, we present the results of a controlled experiment conducted to assess whether the presence of unreachable methods in source code affects source code comprehensibility and modifiability. A total of 47 undergraduate students at the University of Basilicata participated in this experiment. We divided the participants in two groups. The participants in the first group were asked to comprehend code base containing unreachable methods and implement five change requests in that code base. The participants in the second group were asked to accomplish exactly the same tasks as the participants in the first group, however, the source code provided to them did not contain any unreachable methods. The results of the study indicate that code comprehensibility is significantly higher when source code does not contain unreachable methods. However, we did not observe a statistically significant difference for code modifiability. From these results, we distill lessons and implications for practitioners as well as possible avenues for further research.