How do developers use dynamic features? The case of Ruby

https://doi.org/10.1016/j.cl.2018.02.001Get rights and content

Highlights

  • An empirical study that investigates how developers use dynamic features based on 28 open-source Ruby projects.

  • Dynamic feature usage in Ruby ranges from 2.08% to 3.08% at a 95% confidence interval. We could statistically assert that require is more used than any other dynamic feature.

  • On average 49.7% of the dynamic features could be feasibly converted to static code.

  • We identified, classified, and also illustrated the ten most common scenarios where developers prefer to use dynamic features rather than static ones.

  • We have identified five motivations why developers use dynamic statements: unusual coding style, overpassing privacy restrictions, defining new structures, contextualizing block executions, and generalizing code tasks.

Abstract

Programming languages provide features that allow developers—at run time—to evaluate strings as expressions, to define and invoke methods, etc. Nevertheless, the overuse of dynamic features may negatively impact performance, decrease the accuracy of static code analysis techniques, and hinder compiler optimizations. This paper, therefore, investigates how developers use dynamic features based on 28 open-source Ruby projects. The main findings are fourfold: (i) dynamic features correspond on average to 2.58% of the language features in a Ruby project, and almost half of them are send when we disregard features that are ascribed to common programming practices; (ii) we identified that 1417 out of 2849 dynamic statements (49.7%) could be easily converted to static code; (iii) 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.35%), which reveals flaws in the architectural design; and (iv) 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.

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 send 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 include, require, respond_to, and attr variants features, we disregard those from this point on. For example, when developers remove an include or require 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 send. Thus, we claim

Acknowledgment

Our research is supported by CNPq (National Council for Scientific and Technological Development) Grant number 460401/2014-9.

References (14)

  • S. Hanenberg

    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)
  • O. Callaú et al.

    How (and why) developers use the dynamic features of programming languages: the case of Smalltalk

    Empir. Softw. Eng.

    (2013)
  • O. Callaú et al.

    How developers use the dynamic features of programming languages: the case of Smalltalk

    8th working conference on mining software repositories (MSR)

    (2011)
  • M. Hills

    Evolution of dynamic feature usage in PHP

    22nd international conference on software analysis, evolution, and reengineering (SANER)

    (2015)
  • M. Hills et al.

    An empirical study of PHP feature usage: a static analysis perspective

    International symposium on software testing and analysis (ISSTA)

    (2013)
  • A. Holkner et al.

    Evaluating the dynamic behaviour of Python applications

    32nd Australasian conference on computer science (ACSC)

    (2009)
  • J. Palsberg et al.

    Object-oriented type inference

    6th international conference on object-oriented programming, systems, languages, and applications (OOPSLA)

    (1991)
There are more references available in the full text version of this article.

Cited by (4)

View full text