How do developers use dynamic features? The case of Ruby
Introduction
Programming languages provide features that allow developers—at run time—to evaluate strings as expressions, to define and invoke methods, etc. In a nutshell, these dynamic features promote flexibility at many levels [1]. As an example, developers can write a few dynamic statements that are responsible for adapting the code in several scenarios. This results in fewer lines of code and higher changeability.
Nevertheless, the overuse of dynamic features might be undesired. Essentially, their usage may jeopardize the accuracy of static analysis techniques [2], [3], [4], [5], [6] and may cause the loss of legibility, maintainability, etc. [7]. For instance, (i) it may jeopardize early error detection and optimizations by compilers [8]; (ii) it may reduce the accuracy of type inference algorithms (especially in dynamically typed languages), which can hide type errors [9] or architectural violations [10]; (iii) it may inhibit IDE features, such as auto-complete and refactoring tasks [7]; and (iv) it may make the software more complex to understand, which impacts negatively on program comprehension.
In view of such circumstances, this paper investigates how developers use dynamic features based on 28 open-source Ruby projects (which include more than a half million lines of code). From the results from our empirical study, we can point out four main findings:
- 1.
On average, dynamic features correspond to 2.58% of the language features in a Ruby project. Almost 50% of them are when we disregard features that are ascribed to common programming practices. Stated differently, lines of code that contain dynamic statements correspond to 4.68% and methods that contain dynamic statements correspond to 7.46%.
- 2.
We identified that 1417 out of 2849 dynamic statements (49.7%) could be easily converted to static code. This percentage increases to 60.75% and 60.55% for the domains Applications and Frameworks, respectively.
- 3.
We identified, classified, and also illustrated the ten most common scenarios where developers opt for dynamic statements instead of static ones, e.g., we found that developers rely mostly on dynamic features to access private members (20.36%), which reveals flaws in the architectural design.
- 4.
We identified five motivations why developers use dynamic features: unusual coding style, overpassing privacy restrictions, defining new structures, contextualizing block executions, and generalizing code tasks.
The remainder of this paper is organized as follows. Section 2 presents our study setup. Sections 3–6 present and discuss the results of each research question. Section 7 enumerates threats to validity. Finally, Section 8 presents related work and Section 9 concludes the paper.
Section snippets
Research questions
We designed a study to address the following overarching research questions:
RQ #1 - How often do developers use dynamic features?
RQ #2 - How complex is removal of dynamic features?
RQ #3 - When do developers use dynamic features?
RQ #4 - Why do developers use dynamic features?
Dynamic features in Ruby
Ruby is a dynamically and strongly typed language. Regarding dynamic features, Ruby provides functions to dynamically invoke methods, define blocks, and execute strings as code. Each of the dynamic features handled in this
How often do developers use dynamic features? (RQ #1)
In this research question, our goal is to measure the frequency of use of dynamic features in Ruby.
How complex is removal of dynamic features? (RQ #2)
The complexity to remove dynamic features is a crucial factor to our study since it is directly linked with the need for dynamic statements. We claim the more trivial it is to remove dynamic features, the more superfluous their usages are. Since there is no direct benefit in removing the and variants features, we disregard those from this point on. For example, when developers remove an or statement, they would have to locally copy the used
When do developers use dynamic features? (RQ #3)
This research question aims to identify, classify, and illustrate the scenarios where developers opt for dynamic statements instead of static ones.
Why do developers use dynamic features? (RQ #4)
This research question investigates the advantages and disadvantages of dynamic features, which allows us to conjecture why developers use them.
Threats to validity
We must state at least three threats to validity of the reported evaluation. First, our study investigated the use of dynamic features in 28 Ruby projects. As usual in empirical studies in software engineering, we cannot claim that our approach will provide equivalent results in other systems or other dynamically typed languages (external validity). However, we argue there is heterogeneity among the projects since they have been developed by different teams and they belong to different domains,
Related work
We divided the related work into three groups: (i) Empirical studies of Smalltalk; (ii) dynamic features in dynamically typed languages; and (iii) dynamic features in Ruby.
Conclusion
This study investigated how developers use dynamic features based on 28 open-source Ruby projects. First, dynamic feature usage in Ruby ranges from 2.08% to 3.08% at a 95% confidence interval. We claim the more flexibility the system requires, the higher the usage of dynamic features (which reached up to 5.09% in Paperclip). When we disregard features that are ascribed to common programming practices—such as the standard use of require—almost 50% of dynamic usages refer to . Thus, we claim
Acknowledgment
Our research is supported by CNPq (National Council for Scientific and Technological Development) Grant number 460401/2014-9.
References (14)
An experiment about static and dynamic type systems: doubts about the positive impact of static type systems on development time
25th international conference on object-oriented programming, systems, languages, and applications (OOPSLA)
(2010)- et al.
How (and why) developers use the dynamic features of programming languages: the case of Smalltalk
Empir. Softw. Eng.
(2013) - et al.
How developers use the dynamic features of programming languages: the case of Smalltalk
8th working conference on mining software repositories (MSR)
(2011) Evolution of dynamic feature usage in PHP
22nd international conference on software analysis, evolution, and reengineering (SANER)
(2015)- et al.
An empirical study of PHP feature usage: a static analysis perspective
International symposium on software testing and analysis (ISSTA)
(2013) - et al.
Evaluating the dynamic behaviour of Python applications
32nd Australasian conference on computer science (ACSC)
(2009) - et al.
Object-oriented type inference
6th international conference on object-oriented programming, systems, languages, and applications (OOPSLA)
(1991)
Cited by (4)
An Empirical Study on the Impact of Python Dynamic Typing on the Project Maintenance
2022, International Journal of Software Engineering and Knowledge EngineeringAn Empirical Study for Common Language Features Used in Python Projects
2021, Proceedings - 2021 IEEE International Conference on Software Analysis, Evolution and Reengineering, SANER 2021Type freezing: Exploiting attribute type monomorphism in tracing JIT compilers
2020, CGO 2020 - Proceedings of the 18th ACM/IEEE International Symposium on Code Generation and OptimizationRefactorings for replacing dynamic instructions with static ones: The case of ruby
2018, ACM International Conference Proceeding Series