Smart contracts (SC) are software codes which reside and run over a blockchain. The code can be written in different languages with the common purpose of implementing various kinds of transactions onto the hosting blockchain, They are ruled by the blockchain infrastructure and work in order to satisfy conditions typical of traditional contracts. The software code must satisfy constrains strongly context dependent which are quite different from traditional software code. In particular, since the bytecode is uploaded in the hosting blockchain, size, computational resources, interaction between different parts of software are all limited and even if the specific software languages implement more or less the same constructs of traditional languages there is not the same freedom as in normal software development. SC software is expected to reflect these constrains on SC software metrics which should display metric values characteristic of the domain and different from more traditional software metrics. We tested this hypothesis on the code of more than twelve thousands SC written in Solidity and uploaded on the Ethereum blockchain. We downloaded the SC from a public repository and computed the statistics of a set of software metrics related to SC and compared them to the metrics extracted from more traditional software projects. Our results show that generally Smart Contracts metrics have ranges more restricted than the corresponding metrics in traditional software systems. Some of the stylized facts, like power law in the tail of the distribution of some metrics, are only approximate but the lines of code follow a log normal distribution which reminds of the same behavior already found in traditional software systems.
More recently affect metrics have been investigated revealing how during software development productivity and software quality can be highly influenced by developers moods @cite_57 @cite_54 @cite_31 @cite_0 @cite_62 , analyzing in deep details the properties of affect data in software development @cite_23 @cite_25 @cite_65 @cite_43 @cite_21 and building tool for recognize emotions in software developers' text @cite_72 @cite_6 @cite_67 @cite_69 .
@cite_67 @cite_62 @cite_69 @cite_54 @cite_21 @cite_65 @cite_6 @cite_57 @cite_0 @cite_43 @cite_72 @cite_23 @cite_31 @cite_25
2623177746 2779931473 2213700299 1975672192 2617883065 2402365003
Software development—just like any other human collaboration—inevitably evokes emotions like joy or sadness, which are known to affect the group dynamics within a team. Today, little is known about those individual emotions and whether they can be discerned at all in the development artifacts produced during a project. This paper analyzes (a) whether issue reports—a common development artifact, rich in content—convey emotional information and (b) whether humans agree on the presence of these emotions. From the analysis of the issue comments of 117 projects of the Apache Software Foundation, we find that developers express emotions (in particular gratitude, joy and sadness). However, the more context is provided about an issue report, the more human raters start to doubt and nuance their interpretation. Based on these results, we demonstrate the feasibility of a machine learning classifier for identifying issue comments containing gratitude, joy and sadness. Such a classifier, using emotion-driving words and technical terms, obtains a good precision and recall for identifying the emotion love, while for joy and sadness a lower recall is obtained. Building an effective team of developers is a complex task faced by both software companies and open source communities. The problem of forming a “dream” team involves many variables, including consideration of human factors and it is not a dilemma solvable in a mathematical way. Empirical studies might provide interesting insights to explain which factors need to be taken into account in building a team of developers and which levers act to optimise productivity among developers. In this paper, we present the results of an empirical study aimed at investigating the link between team diversity (i.e., gender, nationality) and productivity (issue fixing time). We consider issues solved from the GHTorrent dataset inferring gender and nationality of each team’s members. We also evaluate the politeness of all comments involved in issue resolution. Results show that higher gender diversity is linked with a lower team average issue fixing time (higher productivity), that nationality diversity is linked with lower team politeness and that gender diversity is linked with higher sentiment. The research presented in this paper was partly funded by the Engineering and Physical Sciences Research Council (EPSRC) of the UK under grant ref: EP M024083 1. Micro patterns can be a useful proxy for the quality of software. Classes matching certain categories of micro patterns were shown to be more fault prone than others, and those classes that do not correspond to any category of micro patterns were shown to be more likely to be faulty. In this paper we present a preliminary study of traditional software metrics and micro patterns in three versions of Eclipse (2.1, 3.0, 3.1) in order to understand if it is possible to relate the stability of a software system with micro patterns. The role of emotions and human aspects of software development is gaining increasing attention from both academics and developers. Software development is a complex activity, but since software is everywhere and it is necessary to achieve the highest quality possible. High technical skills, knowledge and competence of a software developer are not the only factors which influence the final product. Good attitudes, communication skills and good manners are equally as important. In this paper we focused our attention on understanding how developer sentiment and emotions evolved over time during the development process of 10 systems, considering affectiveness as time series. We studied seasonality, randomness and correlations. Results showed that there was not a significant correlation among joy and love, sadness and anger, sentiment and joy. Regarding seasonality and randomness, results showed that in the majority of the cases, the analysed time series are seasonal and not random. ABSTRACTIssue tracking systems store valuable data for testing hy-potheses concerning maintenance, building statistical pre-diction models and (recently) investigating developer affec-tiveness. For the latter, issue tracking systems can be minedto explore developers emotions, sentiments and politeness, affects for short. However, research on affect detection insoftware artefacts is still in its early stage due to the lack ofmanually validated data and tools.In this paper, we contribute to the research of affectson software artefacts by providing a labeling of emotionspresent on issue comments.We manually labeled 2,000 issue comments and 4,000 sen-tences written by developers with emotions such as love,joy, surprise, anger, sadness and fear. Labeled commentsand sentences are linked to software artefacts reported inour previously published dataset (containing more than 1Kprojects, more than 700K issue reports and more than 2million issue comments). The enriched dataset presented inthis paper allows the investigation of the role of affects insoftware development.