In software engineering, relying on experience can render maintainability expertise into prejudice over time. For example, based on their own experience, some consider JavaScript as inelegant language and hence of lowest maintainability. Such prejudice should not guide decisions without prior empirical validation.
Static analysis has been used by other researchers to investigate the quality of open-source code. But most of that research considers few software applications or few programming languages. @cite_15 and @cite_22 present studies on code quality of open-source code. @cite_31 present a study on open-source code, investigating the impact of team size on code quality. All three papers also use static analysis to measure code quality, they use different metrics, which we consider less suitable for maintainability. Furthermore, they do not investigate the impact of programming language or other factors on quality. Ahmed, Ghorashi and Jensen @cite_32 investigate the code quality of open-source code by examining the correlation between code smells and project characteristics. They do not investigate the impact of programming language and use different static analysis metrics.
@cite_15 @cite_32 @cite_31 @cite_22
131006540 2077139938 2120981580 2104074028
Open Source Softwares provide a rich resource of empirical research in software engineering. Static code metrics are a good indicator of software quality and maintainability. In this work we have tried to answer the question whether bug predictors obtained from one project can be applied to a different project with reasonable accuracy. Two open source projects Firefox and Apache HTTP Server (AHS) are used for this study. Static code metrics are calculated for both projects using in-house software and the bug information is obtained from bug databases of these projects. The source code files are classified as clean or buggy using the Decision tree classifier. The classifier is trained on metrics and bug data of Firefox and tested on Apache HTTP Server and vice versa. The results obtained vary with different releases of these projects and can be as good as 92 of the files correctly classified and as poor as 68 of the files correctly classified by the trained classifier. The quality of source code is a key factor for any software product and its continuous monitoring is an indispensable task for a software development project. We have developed a method for systematic assessing and improving the code quality of ongoing projects by using the results of various static code analysis tools. With different approaches for monitoring the quality (a trend-based one and a benchmarking-based one) and an according tool support we are able to manage the large amount of data that is generated by these static analyses. First experiences when applying the method with software projects in practice have shown the feasibility of our method. At the University of Maryland, we have been working to improve the reliability and security of software by developing new, effective static analysis tools. These tools scan software for bug patterns or show that the software is free from a particular class of defects. There are two themes common to our different projects: 1. Our ultimate focus is on utility: can a programmer actually improve the quality of his or her software using an analysis tool? The important first step toward answering this question is to engineer tools so that they can analyze existing, nontrivial programs, and to carefully report the results of such analyses experimentally. The desire to better understand a more human-centered notion of utility underlies much of our future work. 2. We release all of our tools open source. This allows other researchers to verify our results, and to reuse some or all of our implementations, which often required significant effort to engineer. We believe that releasing source code is important for accelerating the pace of research results software quality, and just as importantly allows feedback from the wider community. In this research group presentation, we summarize some recent work and sketch future directions. The paper presents an adaptive approach to perform impact analysis from a given change request to source code. Given a textual change request (e.g., a bug report), a single snapshot (release) of source code, indexed using Latent Semantic Indexing, is used to estimate the impact set. Should additional contextual information be available, the approach configures the best-fit combination to produce an improved impact set. Contextual information includes the execution trace and an initial source code entity verified for change. Combinations of information retrieval, dynamic analysis, and data mining of past source code commits are considered. The research hypothesis is that these combinations help counter the precision or recall deficit of individual techniques and improve the overall accuracy. The tandem operation of the three techniques sets it apart from other related solutions. Automation along with the effective utilization of two key sources of developer knowledge, which are often overlooked in impact analysis at the change request level, is achieved. To validate our approach, we conducted an empirical evaluation on four open source software systems. A benchmark consisting of a number of maintenance issues, such as feature requests and bug fixes, and their associated source code changes was established by manual examination of these systems and their change history. Our results indicate that there are combinations formed from the augmented developer contextual information that show statistically significant improvement over stand-alone approaches.