Context: Concerns have been raised from many quarters regarding the reliability of empirical research findings and this includes software engineering. Replication has been proposed as an important means of increasing confidence. Objective: We aim to better understand the value of replication studies, the level of confirmation between replication and original studies, what confirmation means in a statistical sense and what factors modify this relationship. Method: We perform a systematic review to identify relevant replication experimental studies in the areas of (i) software project effort prediction and (ii) pair programming. Where sufficient details are provided we compute prediction intervals. Results: Our review locates 28 unique articles that describe replications of 35 original studies that address 75 research questions. Of these 10 are external, 15 internal and 3 internal-same-article replications. The odds ratio of internal to external (conducted by independent researchers) replications of obtaining a 'confirmatory' result is 8.64. We also found incomplete reporting hampered our ability to extract estimates of effect sizes. Where we are able to compute replication prediction intervals these were surprisingly large. Conclusion: We show that there is substantial evidence to suggest that current approaches to empirical replications are highly problematic. There is a consensus that replications are important, but there is a need for better reporting of both original and replicated studies. Given the low power and incomplete reporting of many original studies, it can be unclear the extent to which a replication is confirmatory and to what extent it yields additional knowledge to the software engineering community. We recommend attention is switched from replication research to meta-analysis.

During the lifetime of object-Oriented (OO) software systems, new classes are added to increase functionality, also increasing the inter-dependencies between classes. Logical coupling depicts the change dependencies between classes, while structural coupling measures source code dependencies induced via the system architecture. The relationship or dependency between logical and structural coupling have been debated in the past, but no large study has confirmed yet their interplay. In this study, we have analysed 79 open-source software projects of different sizes to investigate the interplay between the two types of coupling. First, we quantified the overlapping or intersection of structural and logical class dependencies. Second, we statistically computed the correlation between the strengths of logical and structural dependencies. Third, we propose a simple technique to determine the stability of OO software systems, by clustering the pairs of classes as "stable" or "unstable", based on their co-change pattern. The results from our statistical analysis show that although there is no strong evidence of a linear correlation between the strengths of the coupling types, there is substantial evidence to conclude that structurally coupled class pairs usually include logical dependencies. However, not all co-changed class pairs are also linked by structural dependencies. Finally, we identified that only a low proportion of structural coupling shows excessive instability in the studied OSS projects.

Context: Conceptual coupling is a measure of how loosely or closely related two software artifacts are, by considering the semantic information embedded in the comments and identifiers. This type of coupling is typically evaluated using the semantic information from source code into a words corpus. The extraction of words corpora can be lengthy, especially when systems are large and many classes are involved.Goal: This study investigates whether using only the class identifiers (e.g., the class names) can be used to evaluate the conceptual coupling between classes, as opposed to the words corpora of the entire classes.Method: In this study, we analyze two Java systems and extract the conceptual coupling between pairs of classes, using (i) a corpus-based approach; and (ii) two identifierbased tools.Results: Our results show that measuring the semantic similarity between classes using (only) their identifiers is similar to using the class corpora. Additionally, using the identifiers is more efficient in terms of precision, recall, and computation time.Conclusions: Using only class identifiers to measure their semantic similarity can save time on program comprehension tasks for large software projects; the findings of this paper support this hypothesis, for the systems that were used in the evaluation and can also be used to guide researchers developing future generations of tools supporting program comprehension.

Context: Long-term software projects employ different software developers who collaborate on shared artifacts. The accumulation of changes pushed by different developers leave traces on the underlying code, that have an effect on its future maintainability, and even reuse.Objective: This study focuses on the how the changes by different developers might have an impact on the code: we investigate whether the work of multiple developers, and their experience, have a visible effect on the structural metrics of the underlying code.Method: We consider nine object-oriented (OO) attributes and we measure them in a GitHub sample containing the top 200 'forked' projects. For each of their classes, we evaluated the number of distinct developers contributing to its source code, and their experience in the project.Results: We show that the presence of multiple developers working on the same class has a visible effect on the chosen OO metrics, and often in the opposite direction to what the guidelines for each attribute suggest. We also show how the relative experience of developers in a project plays an important role in the distribution of those metrics, and the future maintenance of the Java classes.Conclusions: Our results show how distributed development has an effect on the structural attributes of a software system and how the experience of developers plays a fundamental role in that effect. We also discover workarounds

A smart contract (SC) is a programme stored in the Ethereum blockchain by a contract-creation transaction. SC developers deploy an instance of the SC and attempt to execute it in exchange for a fee, paid in Ethereum coins (Ether). If the computation needed for their execution turns out to be larger than the effort proposed by the developer (i.e., the gasLimit), their client instantiation will not be completed successfully. In this paper, we examine SCs from 11 Ethereum blockchain-oriented software projects hosted on GitHub.com, and we evaluate the resources needed for their deployment (i.e., the gasUsed). For each of these contracts, we also extract a suite of object-oriented metrics, to evaluate their structural characteristics. Our results show a statistically significant correlation between some of the object-oriented (OO) metrics and the resources consumed on the Ethereum blockchain network when deploying SCs. This result has a direct impact on how Ethereum developers engage with a SC: evaluating its structural characteristics, they will be able to produce a better estimate of the resources needed to deploy it. Other results show specific source code metrics to be prioritised based on application domains when the projects are clustered based on common themes. KEYWORDS abstract syntax-tree (AST), blockchain-oriented software (BOS), Chidamber and Kemerer (C&K), object-oriented (OO), object-oriented programming (OOP), smart contract (SC) 1 INTRODUCTION A blockchain is a shared ledger that stores transactions in a decentralised 1 peer-to-peer network of computers also known as nodes. Blockchain transactions can be composed of contract creation transactions and contract function invoking transactions. The former deploys and records a smart contract (SC) on the blockchain, and the latter causes the execution of a contract functionality. 2,3 The third transaction type is the token or cryptocurrency transfer transaction such as Bitcoin transfers on the Bitcoin Blockchain or Ether transfers on the Ethereum Blockchain. As a whole, the blockchain technology provides a decentralised, trustless platform that combines transparency, immutability and consensus properties to enable secure, pseudo-anonymous transactions. SCs are the programmes stored in a blockchain by a contract-creation transaction. In the last few years, SCs have been used in different scenarios: in voting platforms to secure votes; to automatically process insurance claims according to agreed terms and postal companies for payments on delivery. 5 Porru et al 6 defined the term blockchain-oriented software (BOS) as a software that contributes to the realization of a blockchain project. This definition includes both blockchain platforms (or networks), such as Bitcoin and Ethereum, and general blockchain software commonly referred to as decentralised apps (DApps). 7 This is an open access article under the terms of the Creative Commons Attribution-NonCommercial License, which permits use, distribution and reproduction in any medium, provided the original work...