Managing cross-project dependencies is tricky in modern software development. A primary way to manage dependencies is using dependency configuration files, which brings convenience to the entire software ecosystem, including developers, maintainers, and users. However, developers may introduce dependency smells if dependency configuration files are not well written and maintained. Dependency smells are recurring violations of dependency management in dependency configuration files and can potentially lead to severe consequences. This paper provides an in-depth look at three dependency smells, namely,Missing Dependency,Bloated Dependency, andVersion Constraint Inconsistencyin Python projects. First, we implement a tool calledPythonCross-projectDependency- PyCD to accurately extract dependency information from configuration files. The evaluation result on 212 Python projects shows that PyCD outperforms state-of-the-art tools. Then, we make an empirical study for three dependency smells in 132 Python projects to investigate the pervasiveness, causes, and evolution. The results show that: 1) dependency smells are prevalent in Python projects and exist inconsistently in different projects; 2) dependency smells are introduced into Python projects for different reasons, mainly due to the problems of synchronous update and collaborative development; and 3) dependency smells can be removed with different patterns according to different dependency smells. Furthermore, we report and get responses for 40 harmful dependency smell instances, 34 of which have been responded that these dependency smells do exist in the projects, and 10 instances are fixed or under process. The feedback from developers indicates that dependency smells can have a negative impact on project maintenance. Our study highlights that these dependency smells deserve the attention of developers.

Knowing the effectiveness of a test suite is essential for many activities such as assessing the test adequacy of code and guiding the generation of new test cases. Mutation testing is a commonly used defect injection technique for evaluating the effectiveness of a test suite. However, it is usually computationally expensive, as a large number of mutants (buggy versions) are needed to be generated from a production code under test and executed against the test suite. In order to reduce the expensive testing cost, recent studies proposed to use supervised models to predict the effectiveness of a test suite without executing the test suite against the mutants. Nonetheless, the training of such a supervised model requires labeled data, which still depends on the costly mutant execution. Furthermore, existing models are based on traditional supervised learning techniques, which assume that the training and testing data come from the same distribution. But, in practice, software systems are subject to considerable concept drifts, i.e., the same distribution assumption usually does not hold. This can lead to inaccurate predictions of a learned supervised model on the target code as time progresses. To tackle these problems, in this paper, we propose a Coverage-Based Unsupervised Approach (CBUA) for evaluating the effectiveness of a test suite. Given a production code under test, the corresponding mutants, and a test suite, CBUA first collects the coverage information of the mutated statements in the target production code under the execution of the test suite. Then, CBUA employs coverage to estimate the probability of each mutant being alive. As such, a mutation score is computed to evaluate the test suite effectiveness and the predicted labels (i.e., killed or alive) are obtained. The whole process only requires a one-time execution of the test suite against the target production code, without involving any mutant execution and any training data. CBUA can ensure the score monotonicity property (i.e., adding test cases to a test suite does not decrease its mutation score), which may be violated by a supervised approach. The experimental results show that CBUA is very competitive with the state-of-the-art supervised approaches in prediction accuracy. In particular, CBUA is shown to be more effective in finding mutants that are covered but not killed by a test suite, which is helpful in identifying the weaknesses in the current test suite and generating new test cases accordingly. Since CBUA is an easy-to-implement approach with a low cost, we suggest that it should be used as a baseline approach for comparison when any novel prediction approach is proposed in future studies.

Software projects are increasingly forming social-technical ecosystems within which individual projects rely on the infrastructures or functional components provided by other projects, leading to complex inter-dependencies. Through inter-project dependencies, a bug in an upstream project may have profound impact on a large number of downstream projects, resulting in cross-project bugs. This emerging type of bugs has brought new challenges in bug fixing due to their unclear influence on downstream projects. In this paper, we present an approach to estimating the impact of a cross-project bug within its ecosystem by identifying the affected downstream modules (classes/methods). Note that a downstream project that uses a buggy upstream function may not be affected as the usage does not satisfy the failure inducing preconditions. For a reported bug with the known root cause function and failure inducing preconditions, we first collect the candidate downstream modules that call the upstream function through an ecosystem-wide dependence analysis. Then, the paths to the call sites of the buggy upstream function are encoded as symbolic constraints. Solving the constraints, together with the failure inducing preconditions, identifies the affected downstream modules. Our evaluation of 31 existing upstream bugs on the scientific Python ecosystem containing 121 versions of 22 popular projects (with a total of 16 millions LOC) shows that the approach is highly effective: from the 25490 candidate downstream modules that invoke the buggy upstream functions, it identifies 1132 modules where the upstream bugs can be triggered, pruning 95.6% of the candidates. The technique has no false negatives and an average false positive rate of 7.9%. Only 49 downstream modules (out of the 1132 we found) were reported before to be affected.

The dynamic typing discipline of Python allows developers to program at a high level of abstraction. However, type related bugs are commonly encountered in Python systems due to the lack of type declaration and static type checking. Especially, the misuse of dynamic typing discipline produces underlying bugs and increases maintenance efforts. In this paper, we introduce six types of dynamic typing related practices in Python programs, which are the common but potentially risky usage of dynamic typing discipline by developers. We also implement a tool named PYDYPE to detect them. Based on this tool, we conduct an empirical study on nine real-world Python systems (with the size of more than 460KLOC) to understand dynamic typing related practices. We investigate how widespread the dynamic typing related practices are, why they are introduced into the systems, whether their usage correlates with increased likelihood of bug occurring, and how developers fix dynamic typing related bugs. The results show that: (1) dynamic typing related practices exist inconsistently in different systems and Inconsistent Variable Types is most prevalent; (2) they are introduced into systems mainly during early development phase to promote development efficiency; (3) they have a significant positive correlation with bug occurring; (4) developers tend to add type checks or exception handling to fix dynamic typing related bugs. These results benefit future research in coding convention, language design, bug detection and fixing.

Generic programming is a key paradigm for developing reusable software components. The inherent support for generic constructs is therefore important in programming languages. As for C++, the generic construct, templates, has been supported since the language was first released. However, little is currently known about how C++ templates are actually used in developing real software. In this study, we conduct an experiment to investigate the use of templates in practice. We analyze 1,267 historical revisions of 50 open source systems, consisting of 566 million lines of C++ code, to collect the data of the practical use of templates. We perform statistical analyses on the collected data and produce many interesting results. We uncover the following important findings: (1) templates are practically used to prevent code duplication, but this benefit is largely confined to a few highly used templates; (2) function templates do not effectively replace C-style generics, and developers with a C background do not show significant preference between the two language constructs; (3) developers seldom convert dynamic polymorphism to static polymorphism by using CRTP (Curiously Recursive Template Pattern); (4) the use of templates follows a power-law distribution in most cases, and C++ developers who prefer using templates are those without other language background; (5) C developer background seems to override C++ project guidelines. These findings are helpful not only for researchers to understand the tendency of template use but also for tool builders to implement better tools to support generic programming.

Software systems becomes increasingly complex for the wide use of social-software-development platforms, such as GitHub. Complicated inter-dependencies within ecosystems impose new challenges in resolving the blocking bug pairs, in which the upstream bugs prevent the downstream bugs to be fixed. Generally, the downstream bugs cannot be fixed until the upstream bugs are fixed in blocking bug pairs, which keeps the downstream developers waiting for a long time. However, previous research found that some blocking pairs could be "broken" through a workaround, i.e., a temporary solution proposed by the downstream developers before the upstream bugs get fixed. In this paper, we propose an approach to describe and predict the breakability of the blocking bug pairs. Our goal is to help the ecosystem developers to predict whether the given blocking bug pair can be broken. We evaluate our approach on two real world ecosystems: Mozilla Firefox and Netbeans, and have the following two main findings. First, the participants within the blocking bug pair and the vitality of the downstream bug have much impact on the breakability. Second, we can build breakability predication models with the accuracy of approximate 80%. Moreover, for predicting unbreakable pairs which affect the downstream projects seriously, our approach achieves a precision over 92%. It can be used to effectively remind the upstream developers to fix these bugs as quickly as possible.

Code smells are used to describe the bad structures in the source code, which could hinder software maintainability, understandability and changeability. Nowadays, scholars mainly focus on the impact of smell on textual change-proneness. However, in comparison to textual changes, structural changes could better reveal the change nature. In practice, not all code change types are equally important in terms of change risk severity levels, and software developers are more interested in particular changes relevant to their current tasks. Therefore, we investigate the relationship between smells and fine-grained structural change-proneness to solve these issues. Our experiment was conducted on 11 typical open source projects. We first employed Fishers exact test and Mann–Whitney test to explore whether smelly files (affected by at least one smell type) had higher structural change-proneness than other files, and whether files with more smell instances are more likely to undergo structural changes, respectively. Multivariate logistic regression model was built to study the relation between each kind of smell and change-proneness with respect to five change categories. Our results showed that: (1) in most cases, smelly files were more prone to structural changes and files with more smell instances tend to undergo higher structural changes; (2) quite a few smell types were related to structural change-proneness, particularly, Refused Parent Bequest (RPB), Message Chains (MCH), Divergent Change (DIVC), Feature Envy (FE) and Shotgun Surgery (SS) increased structural changes for some change categories. However, when controlling the file size Lines of Code (LOC), significant change-proneness of some smells disappeared or the magnitude of significance decreased more or less.

Continuous Integration (CI) has become a good practice of software development in recent years. As an essential part of CI, build creates software from source code. Predicting build outcome help developers to review and fix bugs before building to save time. However, we are missing objective evidence of practical factors affecting build result. Travis CI provides a hosted, distributed continuous integration service used to build and test software projects hosted at GitHub. The TravisTorrent is a dataset which deeply analyzes source code, process and dependency status of projects hosting on Travis CI. We use this dataset to investigate which factors may impact a build result. We first preprocess TravisTorrent data to extract 27 features. We then analyze the correlation between these features and the result of a build. Finally, we build four prediction models to predict the result of a build and perform a horizontal analysis. We found that in our study, the number of commits in a build (git_num_all_built_commits) is the most import factor that has significant impact on the build result, and SVM performs best in the four of the prediction models we used.

GitHub has fostered complicated and enormous software ecosystems, in which projects depend on and co-evolve with each other. An error in an upstream project may affect its downstream projects through inter-dependencies, forming crossproject bugs. Though the upstream developers should fix the bugs on their side, proposing a workaround, i.e., a temporary solution in the downstream project is a common practice for the downstream developers. In this study, we empirically investigated the characteristics of downstream workarounds in the scientific Python ecosystem. Combining the statistical comparisons and manual inspection, we have the following three main findings. First, in general, the workarounds and the corresponding upstream fixes are significantly different in code size and code structure. Second, there are three kinds of crossproject bugs that the downstream developers usually work around. Last, four types of common patterns are identified from the investigated workarounds. The findings of this study lead to better understanding of cross-project bugs and the practices of developers in software ecosystems.

GitHub, a popular social-software-development platform, has fostered a variety of software ecosystems where projects depend on one another and practitioners interact with each other. Projects within an ecosystem often have complex inter-dependencies that impose new challenges in bug reporting and fixing. In this paper, we conduct an empirical study on cross-project correlated bugs, i.e., causally related bugs reported to different projects, focusing on two aspects: 1) how developers track the root causes across projects, and 2) how the downstream developers coordinate to deal with upstream bugs. Through manual inspection of bug reports collected from the scientific Python ecosystem and an online survey with developers, this study reveals the common practices of developers and the various factors in fixing cross-project bugs. These findings provide implications for future software bug analysis in the scope of ecosystem, as well as shed light on the requirements of issue trackers for such bugs.

In recent years, it has been shown that fault prediction models could effectively guide test effort allocation in finding faults if they have a high enough fault prediction accuracy (Norm(Popt) > 0.78). However, it is often difficult to achieve such a high fault prediction accuracy in practice. As a result, fault-prediction-model-guided allocation (FPA) methods may be not applicable in real development environments. To attack this problem, in this paper, we propose a new type of test effort allocation strategy: reliability-growth-model-guided allocation (RGA) method. For a given project release V, RGA attempts to predict the optimal test effort allocation for V by learning the fault distribution information from the previous releases. Based on three open-source projects, we empirically investigate the cost-effectiveness of three test effort allocation strategies for finding faults: RGA, FPA, and structural-complexity-guided allocation (SCA) method. The experimental results show that RGA shows a promising performance in finding faults when compared with SCA and FPA.

Software has been changing during its whole life cycle. Therefore, identification of source code changes becomes a key issue in software evolution analysis. However, few current change analysis research focus on dynamic language software. In this paper, we pay attention to the fine-grained source code changes of Python software. We implement an automatic tool named PyCT to extract 77 kinds of fine-grained source code change types from commit history information. We conduct an empirical study on ten popular Python projects from five domains, with 132294 commits, to investigate the characteristics of dynamic software source code changes. Analyzing the source code changes in four aspects, we distill 11 findings, which are summarized into two insights on software evolution: change prediction and fault code fix. In addition, we provide direct evidence on how developers use and change dynamic features. Our results provide useful guidance and insights for improving the understanding of source code evolution of dynamic language software.

The interactions between anti-patterns are claimed to affect maintenance. However, little work has been conducted to examine how anti-patterns interact. In this paper, we aim to investigate which pairs of anti-patterns tend to be coupled, i.e., interact with each other. We employ Fisher's exact test and Wilcoxon rank-sum test to identify coupled anti-patterns in the same class and coupled classes. Analyzing the relationships amongst 10 kinds of anti-patterns in five open-source projects, our results show that 1) several kinds of anti-patterns tend to be coupled, but some are conflicting, 2) the effect of anti-patterns on their dependent or co-changed ones are significant but small, 3) in ArgoUML, Xalan and Xerces-J, the classes infected with dependent anti-patterns are mostly (69.9% ~ 100%) modified in maintenance activities. Our findings offer empirical evidences for the existence of anti-pattern interactions, which provides valuable implications for practitioners and researchers.

The dynamic features of programming languages are useful constructs that bring developers convenience and flexibility, but they are also perceived to lead to difficulties in software maintenance.Figuring out whether the use of dynamic features affects maintenance is significant for both researchers and practitioners, yet little work has been done to investigate it.In this paper, we conduct an empirical study to explore whether program source code files using dynamic features are more change-prone and whether particular categories of dynamic features are more correlated to change-proneness than others.To this end, we statically analyze historical data from 4 to 7 years of the development of seven open-source systems.We employ Fisher and Mann-Whitney hypothetical test methods, along with logistic regression model to solve three research questions.The results show that: (1) files with dynamic features are more change-prone, (2) files with a higher number of dynamic features are more change-prone, and (3) Introspection is shown to be more correlated to change-proneness than the other three categories in most systems.This innovative work can give some inspirations and references to researchers who are always focusing their eyes on how and why the dynamic features are used.For practitioners, we suggest them to be wary of files with dynamic features because they are more likely to be the subject of their maintenance effort.