Quality Factors and Coding Standards – a Comparison Between Open Source Forges

Electronic Notes in Theoretical Computer Science 233 (2009) 89–103 www.elsevier.com/locate/entcs Quality Factors and Coding Standards – a Comparison Between Open Source Forges Andrea Capiluppi, Cornelia Boldyreff, Karl Beecher Centre of Research on Open Source Software – CROSS Department of Computer Science University of Lincoln, UK Email: {acapiluppi,cboldyreff,kbeecher}@lincoln.ac.uk Paul J. Adams Research and Development, Sirius Corporation Ltd., Weybridge, UK Email: [email protected] Abstract Enforcing adherence to standards in software development in order to produce high quality software artefacts has long been recognised as best practice in traditional software engineering. In a distributed heterogeneous development environment such those found within the Open Source paradigm, coding standards are infor- mally shared and adhered to by communities of loosely coupled developers. Following these standards could potentially lead to higher quality software. This paper reports on the empirical analysis of two major forges where OSS projects are hosted. The first one, the KDE forge, provides a set of guidelines and coding standards in the form of a coding style that developers may conform to when producing the code source artefacts. The second studied forge, SourceForge, imposes no formal coding standards on developers. A sample of projects from these two forges has been analysed to detect whether the SourceForge sample, where no coding standards are reinforced, has a lower quality than the sample from KDE. Results from this analysis form a complex picture; visually, all the selected metrics show a clear divide between the two forges, but from the statistical standpoint, clear distinctions cannot be drawn amongst these quality related measures in the two forge samples. Keywords: Coding Standards, Open Source Software, Complexity. 1 Introduction Programming styles and coding standards form a set of formal rules which are inter- nally shared among programmers, and enforced by software managers [29]. These rules reflect different concerns and affect areas of source code writing, with the aim of improving both the readability of source code and the maintainability of the underlying software system. They range from language-independent typographic styles, as the rules affecting how both the source code and comments are visually 1571-0661/$ – see front matter © 2009 Elsevier B.V. All rights reserved. doi:10.1016/j.entcs.2009.02.063 90 A. Capiluppi et al. / Electronic Notes in Theoretical Computer Science 233 (2009) 89–103 structured and displayed [26,28], to general programming practices relative to specific programming languages (as C++ [16]), paradigms (such as the object-oriented paradigm [21]) or development approaches (such as the Agile methodologies [31]). Research evidence has confirmed the presence of coding standards and programming styles in a wide spectrum of approaches: in commercial, proprietary, software [29], in Agile-driven systems [31] as well as in Open Source software [14]. Past empirical research also suggested that programming styles, applied in both creating new code or maintaining existing programs, have an impact on the quality of the resulting software [28]. In this paper it is argued that, in the presence of coding standards and programming guidelines, the resulting software will display a higher quality than software produced without such a coding framework. Specifically, a study of whether software produced within the Open Source paradigm has higher quality as long as they implement and enforce coding practices is provided. In order to detect the quality of the resulting software, three metrics were collected, both at the granular level of functions (or OO methods), the fan-in, the fan-out (both termed as “coupling”) and the relative cyclomatic complexity. A null hypothesis was formulated: software projects from the sample implementing coding styles and standards will display lower values of complexity and coupling than counterparts from a sample not enforcing the same standards. The first sample (“with treatment”) was randomly extracted from the KDE forge, already known for enforcing these standards and guidelines [14]. The other sample (“without treatment”) was extracted from the SourceForge repository 1 . A statistical test [32] was used to evaluate the signifi- cance of the differences in the two samples. This paper is structured as follows:Section 2 provides a description of past and current research works which can be related to the present paper, and describes how it completes or enhances previous approaches. Section 3 presents the definitions and the attributes used in this work. It also introduces and instantiates the GQM approach [2], tailoring a research question for the current study.Section 4 produces an empirical hypothesis based on the presented research question, illustrating the null and the alternative hypotheses, as well as the complexity and coupling metrics used to evaluate them. In the same section, an overview of the samples from the two forges is also given. Section 5 presents the results of the statistical tests linked to the hypothesis, and evaluates whether the null hypothesis should be rejected or not.Section 6 illustrates both internal and external threats to validity to this empirical study, whileSections 7 and 8 conclude this paper. 2 Related work and Background The research areas related to this work can be divided into three main sections: metrics for software quality, literature on coding standards and styles and related practice including tool support. Regarding the first research area, there is an extensive 1 Even if not clearly stated, it may very well the case that particular projects within SourceForge adhere to coding standards anyway. In the following, it is assumed that this effect is negligible. A. Capiluppi et al. / Electronic Notes in Theoretical Computer Science 233 (2009) 89–103 91 software literature dealing with the measurement of software quality and associated characteristics such as complexity, comprehensibility, reusability and maintainability. Measurements have been traditionally divided into development and design quality metrics (early in the product lifecycle), e.g. [20], and post-release metrics which can be applied to a finished software product. One of the most famous effort in the later area presented the results of the impact of coupling, cohesion and complexity on the development cost of object-oriented systems [4]. Quality measurement has also matured to the point at which a standard has been defined for this activity. The ISO standard for software quality measurement [1] defines the characteristics of software quality as: functionality, reliability, usabil- ity, efficiency, maintainability and portability. In the past, there have been other attempts to determine quality numbers based on source code metrics: the most well- known is the Maintainability Index [27], which is a composite metric to assess, at the system level, the relative maintainability. The Halstead Effort [15], the McCabe cyclomatic complexity, the lines of code and comments are averaged into a single number to represent a global index of maintainability and quality. As reported in other studies [6], the McCabe values typically follow a Power-law distribution for methods or procedures in a system: using the average for such distributions will hinder some of the characteristics of the distribution, such as its skewness. The Halstead Effort metric has been evaluated as highly correlated with the McCabe index [17], but also heavily criticized as an unreliable metric [19]. In this work, the McCabe indexes are evaluated both as distribution in each project, and considering the fraction of highly complex functions (i.e., whose index is larger than 10 [23]). The Halstead Effort as a metric is not considered in this work. Works focusing on open source quality or success often measure endogenous metrics (often “people” or “process” metrics) such as the amount of developer activity, the number of developers, forum activity, version control etc. [8,10,12,25]. A related work examining product metrics by Stamelos et al [30] undertook an analysis of 100 open source programs written for Linux and took a variety of basic static measurements (such as program length, unconditional jumps etc.). These results were compared to “industrial standards” suggested by the measurement tool. The use of coding standards is also well covered in the literature and can be par- tially enforced through automated checkers, such as the UNIX-based lint, developed for the C programming language in the late 1970s [18]. Similar tools were later made commercially available for other programming languages, like the C++ [24]. Within the FLOSS community, there are lint-like tools available and the tool CQual++ is available for both C and C++. The use of CQual++ on Debian packages to im- prove their code quality has been recently reported [7] although it should be noted that this application has taken place after the fact, rather than as a regular practice by the project’s developer community. Also, this tool is mainly focused on code improvement through the elimination of format string vulnerabilities. Within the KDE community, there is an explicit KDE Quality Team 2 and on its webpages, developers are guided towards information regarding Trolltech’s Qt application frame- 2 http://quality.kde.org/ 92 A. Capiluppi et al. / Electronic Notes in Theoretical Computer Science 233 (2009) 89–103 work which is widely the core widget set within development of KDE applications. Coding standards can be automatically enforced by using Parasoft’s Insure++ in conjunction with Qt 3 . Each KDE project has the freedom to develop its own specific Coding Style; projects are recommended to follow the kdelibs coding style 4 .Thereisacod- ing style for kdelibs that is supported by a vim script in kdesdk/scripts/kde-devel- vim.vim that helps developers to keep the coding style correct. In addition to defaulting to the kdelibs coding style it will automatically use the correct style for Solid and kdepim code. Developers can add rules for other projects via the SetCodingStyle function.

Load more