Say my name! An empirical study on the pronounceability of identifier names

Mapping Intimacies ◽

10.5753/vem.2021.17218 ◽

2021 ◽

Author(s):

Remo Gresta ◽

Elder Cirilo

Keyword(s):

Empirical Study ◽

Open Source ◽

Source Code ◽

Complexity Measure ◽

Code Review ◽

Phonetic Similarity ◽

Complexity Score ◽

Review Sessions ◽

Naming Practices

Identifiers represent approximately 2/3 of the elements in source code, and their names directly impact code comprehension. Indeed, intention-revealing names make code easier to understand, especially in code review sessions, where developers examine each other's code for mistakes. However, we argue that names should be understandable and pronounceable to enable developers to review and discuss code effectively. Therefore, we carried out an empirical study based on 40 open-source projects to explore the naming practices of developers concerning word complexity and pronounceability. We applied the Word Complexity Measure (WCM) to discover complex names; and analyzed the phonetic similarity among names and hard-to-pronounce English words. As a result, we observed that most of the analyzed names are somewhat composed of hard-to-pronounce words. The overall word complexity score of the projects also tends to be significant. Finally, the results show that the code location impacts the word complexity: names in small scopes tend to be simpler than names declared in large scopes.

Download Full-text

Why Do Developers Reject Refactorings in Open-Source Projects?

ACM Transactions on Software Engineering and Methodology ◽

10.1145/3487062 ◽

2022 ◽

Vol 31 (2) ◽

pp. 1-23

Author(s):

Jevgenija Pantiuchina ◽

Bin Lin ◽

Fiorella Zampetti ◽

Massimiliano Di Penta ◽

Michele Lanza ◽

...

Keyword(s):

Open Source ◽

Software Quality ◽

Good Practice ◽

Source Code ◽

Code Review ◽

Code Quality ◽

Shed Light

Refactoring operations are behavior-preserving changes aimed at improving source code quality. While refactoring is largely considered a good practice, refactoring proposals in pull requests are often rejected after the code review. Understanding the reasons behind the rejection of refactoring contributions can shed light on how such contributions can be improved, essentially benefiting software quality. This article reports a study in which we manually coded rejection reasons inferred from 330 refactoring-related pull requests from 207 open-source Java projects. We surveyed 267 developers to assess their perceived prevalence of these identified rejection reasons, further complementing the reasons. Our study resulted in a comprehensive taxonomy consisting of 26 refactoring-related rejection reasons and 21 process-related rejection reasons. The taxonomy, accompanied with representative examples and highlighted implications, provides developers with valuable insights on how to ponder and polish their refactoring contributions, and indicates a number of directions researchers can pursue toward better refactoring recommenders.

Download Full-text

Understanding the Causes of Architecture Changes Using OSS Mailing Lists

International Journal of Software Engineering and Knowledge Engineering ◽

10.1142/s0218194015400367 ◽

2015 ◽

Vol 25 (09n10) ◽

pp. 1633-1651 ◽

Cited By ~ 2

Author(s):

Wei Ding ◽

Peng Liang ◽

Antony Tang ◽

Hans van Vliet

Keyword(s):

Grounded Theory ◽

Empirical Study ◽

Open Source ◽

Open Source Software ◽

Source Code ◽

Internal Quality ◽

Functional Requirement ◽

Quality Requirement ◽

External Quality ◽

Mailing Lists

The causes of architecture changes can tell about why architecture changes, and this knowledge can be captured to prevent architecture knowledge vaporization and architecture degeneration. But the causes are not always known, especially in open source software (OSS) development. This makes it very hard to understand the underlying reasons for the architecture changes and design appropriate modifications. Architecture information is communicated in development mailing lists of OSS projects. To explore the possibility of identifying and understanding the causes of architecture changes, we conducted an empirical study to analyze architecture information (i.e. architectural threads) communicated in the development mailing lists of two popular OSS projects: Hibernate and ArgoUML, verified architecture changes with source code, and identified the causes of architecture changes from the communicated architecture information. The main findings of this study are: (1) architecture information communicated in OSS mailing lists does lead to architecture changes in code; (2) the major cause for architecture changes in both Hibernate and ArgoUML is preventative changes, and the causes of architecture changes are further classified to functional requirement, external quality requirement, and internal quality requirement using the coding techniques of grounded theory; (3) more than 45% of architecture changes in both projects happened before the first stable version was released.

Download Full-text

Do Missing Link Community Smell Affect Developers Productivity: An Empirical Study

Knowledge Engineering and Data Science ◽

10.17977/um018v4i12021p29-37 ◽

2021 ◽

Vol 4 (1) ◽

pp. 29

Author(s):

Toukir Ahammed ◽

Sumon Ahmed ◽

Mohammed Shafiul Alam Khan

Keyword(s):

Empirical Study ◽

Open Source ◽

Source Code ◽

Missing Link ◽

Code Smell ◽

Relationship Of ◽

The Relationship

Missing link smell occurs when developers contribute to the same source code without communicating with each other. Existing studies have analyzed the relationship of missing link smells with code smell and developer contribution. However, the productivity of developers involved in missing link smell has not been explored yet. This study investigates how productivity differs between smelly and non-smelly developers. For this purpose, the productivity of smelly and non-smelly developers of seven open-source projects are analyzed. The result shows that the developers not involved in missing link smell have more productivity than the developers involved in smells. The observed difference is also found statistically significant.

Download Full-text

The "Shut the f**k up" Phenomenon: Characterizing Incivility in Open Source Code Review Discussions

Proceedings of the ACM on Human-Computer Interaction ◽

10.1145/3479497 ◽

2021 ◽

Vol 5 (CSCW2) ◽

pp. 1-35

Author(s):

Isabella Ferreira ◽

Jinghui Cheng ◽

Bram Adams

Keyword(s):

Open Source ◽

Source Code ◽

Code Review ◽

Open Source Code

Download Full-text

Contextual Similarity Among Identifier Names: An Empirical Study

10.5753/vem.2020.14528 ◽

2020 ◽

Author(s):

Remo De Oliveira Gresta ◽

Elder Cirilo

Keyword(s):

Empirical Study ◽

Software Development ◽

Open Source ◽

Semantic Similarity ◽

Large Scale ◽

Current Knowledge ◽

Source Code ◽

Word Embedding ◽

Acceptable Level ◽

Domain Information

Identifiers are one of the most important sources of domain information in software development. Therefore, it is recognized that the proper use of names directly impacts the code's comprehensibility, maintainability, and quality. Our goal in this work is to expand the current knowledge about names by considering not only their quality but also their contextual similarity. To achieve that, we extracted names of four large scale open-source projects written in Java. Then, we computed the semantic similarity between classes and their attributes/variables using Fasttext, an word embedding algorithm. As a result, we could observe that source code, in general, preserve an acceptable level of contextual similarity, developers avoid to use names out of the default dictionary (e.g., domain), and files with more changes and maintained by distinct contributors tend to have better a contextual similarity.

Download Full-text

Impact of Clone Refactoring on External Quality Attributes of Open Source Softwares

International Journal of Scientific Research in Computer Science Engineering and Information Technology ◽

10.32628/cseit183833 ◽

2018 ◽

pp. 86-94

Author(s):

Himanshi Vashisht ◽

Sanjay Bharadwaj ◽

Sushma Sharma

Keyword(s):

Open Source ◽

Internal Structure ◽

Software Quality ◽

Source Code ◽

Quality Attributes ◽

Software Component ◽

External Quality ◽

Code Refactoring ◽

Observable Behaviour

Code refactoring is a “Process of restructuring an existing source code.”. It also helps in improving the internal structure of the code without really affecting its external behaviour”. It changes a source code in such a way that it does not alter the external behaviour yet still it improves its internal structure. It is a way to clean up code that minimizes the chances of introducing bugs. Refactoring is a change made to the internal structure of a software component to make it easier to understand and cheaper to modify, without changing the observable behaviour of that software component. Bad smells indicate that there is something wrong in the code that have to refactor. There are different tools that are available to identify and emove these bad smells. A software has two types of quality attributes- Internal and external. In this paper we will study the effect of clone refactoring on software quality attributes.

Download Full-text